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PREFACE 


Throughout  this  Functional  Description  (FD),  every  effort  has  been  made  to 
answer  the  central  questions: 

a.  What  is  AFIRMS? 

b.  Where  is  AFIRMS  now? 

c.  Where  is  AFIRMS  headed? 

d.  How  does  AFIRMS  get  there? 

The  FD  addresses  "What  is  AFIRMS?"  in  detail.  Its  response  to  the 
question  requires  examination  of  many  supporting  questions.  Where  answers  to 
these  supporting  questions  are  not  clearly  known,  that  fact  is  indicated. 
Specific  implementation  needs  relating  to  these  questions  are  identified  in 
the  Analysis  Phase  of  the  initial  implementation  for  each  major  command. 

The  last  three  questions  are  addressed  as  conceptual  needs  in  the  FD.  The 
AFIRMS  Management  Plan  addresses  these  three  questions  in  detail. 
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SECTION  1.  GENERAL 


\ 

1.1  Purpose  o f  the  Functional  Description.  This  Functional  Description  (FD)  for  the  Air 
Force  Integrated  Readiness  Measurement  System  (AFIRMS),  (Contract  No. 
F49642-83-C-0022),  is  written  to  provide: 

a.  The  system  requirements  to  be  satisfied  which  will  serve  as  a  basis  for  mutual 
understanding  between  the  user  and  the  developer. 

b.  .  Information  on  performance  requirements,  preliminary  design,  and  user 

impacts,  including  fixed  and  continuing  costsj  -j.-,-  L 

c.  A  basis  for  the  development  of  system  tests. 

/  - 

This  Functional  Description  discusses  AFIRMS  as  a  fully  operational  system.  Other 
documents  describing  AFIRMS  are  directed  to  the  initial  installation;  that  is,  to  a  subset 
of  the  functions,  as  it  will  occur  in  the  first  major  command  (MAJCOM)  implementations. 

\ 

1.2  Project  References.  Accurate  assessment  of  force  readiness  and  sustainability  has 

been  a  constant  concern  of  Air  Force  commanders  and  their  staffs.  This  concern  has  been 
supported  by  an  intensified  DoD-wide  interest  in  capability.  In  response  to  this  Air  Force 
concern,  the  Directorate  of  Operations  and  Readiness  initiated  the  AFIRMS  Program. 
AFIRMS  has  been  developed  through  a  learning  prototype  and  is  structured  to  provide  Air 
Force  commanders  with  a  complete,  timely,  and  accurate  assessment  of  their  operational 
readiness  and  sustainability.  ('  '  ' 

The  Program  Management  Office  (PMO)  responsible  for  contract  management  of  the 
AFIRMS  Learning  Prototype  Phase  (LPP)  and  this  FD  is  the  Data  Systems  Design  Office 
(DSDO/XO),  Gunter  Air  Force  Station  (AF5),  Alabama;  the  Office  of  Primary 
Responsibility  (OPR)  is  the  United  States  Air  Force  Readiness  Assessment  Group 
(AF/XOOIM).  Three  operational  centers  were  used  as  LPP  testbed  sites:  The  Pentagon, 
Washington,  D.C.;  Headquarters  United  States  Air  Forces  Europe  (HQ  USAFE),  Ramstein 
Air  Base  (AB),  Germany;  and,  the  52nd  Tactical  Fighter  Wing  (TFW),  Spangdahlem  AB, 
Germany. 


References  applicable  to  the  history  and  development  of  the  AFIRMS  Program  are 
listed  below,  along  with  references  concerning  documentation  and  programming  standard 


a.  AFIRMS  Data  Requirements  Document,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

b.  AFIRMS  Economic  Analysis,  Final,  SofTech,  Contract  No.  F49642-83-C-G022, 
31  May  1985.  (Unclassified) 

c.  AFIRMS  Evolutionary  Implementation  Plan,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

d.  AFIRMS  Functional  Description,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

e.  AFIRMS  HQ  USAF  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

f.  AFIRMS  HQ  USAF  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

g.  AFIRMS  HQ  USAFE  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

h.  AFIRMS  HQ  USAFE  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

i.  AFIRMS  Product  Descriptions,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

j.  AFIRMS  System  Specification,  Final,  SofTech,  Contract  No.  F49642-83-C-0022 
31  May  1985.  (Unclassified) 

k.  AFIRMS  Transform  and  Model  Descriptions,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

l.  AFIRMS  Wing  Database  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

m.  AFIRMS  Wing  Subsystem  Specification,  Final,  SofTech,  Contract  No. 
F49642-83-C-0022,  31  May  1985.  (Unclassified) 

n.  System  Interface  Design  tor  the  AFIRMb  LPP  and  the  Combat  Fuels 
Management  System  (CFMS),  SofTech,  Contract  No.  F49642-83-C-0022, 

28  February  1985.  (Unclassified) 

o.  AFR  700-5,  Information  System  Requirements  Board,  9  November  1984. 
(Unclassified) 

p.  System  Interface  Design  for  the  AFIRMS  LPP  and  the  Air  Force  Operations 
Resource  Management  System  (AFORMS),  SofTech,  Contract  No. 
F49642-83-C-0022,  2  November  1984.  (Unclassified) 


AFR  700-2,  Information  Systems  Planning,  26  October  1984.  (Unclassified) 


Automated  Data  Processing  (ADP)  Security  Policy,  Procedures,  and 
Responsibilities,  AFR  205-16,  1  August  1984.  (Unclassified) 

AFR  300-4,  Vol.  4,  Air  Force  Data  Dictionary,  1  May  1984.  (F0U0) 
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*  cc. 
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dd. 

Automated  Data  Systems  (ADS)  Documentation  Standards,  DoD-STD-7935. 1 , 
24  April  1984.  (Unclassified) 


Department  of  Defense  Dictionary  of  Military  and  Associated  Terms, 
JCS  Pub  1,  24  April  1984.  (Unclassified) 


AFR  700-1,  Managing  Air  Force  Information  Systems,  2  March  1984. 
(Unclassified) 


AFIRMS  LPP  ADP  Security  Plan,  SofTech,  Contract  No.  F49642-83-C-0022 , 
13  February  1985.  (F0U0) 


AFR  300-4,  Vol.  3,  Air  Force  Data  Dictionary,  15  August  1983.  (F0U0) 


Sustainability  Assessment  Model  (formerly  CAC)  Functional 
Description,  Contract  No.  F33700-83-G-002005701,  8  April  1983. 
(Unclassified) 


AFR  700-3,  Information  Systems  Requirements  Processing,  30  November 
1984.  (Unclassified) 


MIL- STD-480  Configuration  Control-Engineering  Changes,  Deviations, 
and  Waivers. 


MIL- STD-483  Configuration  Management  Practices  for  Systems, 
Equipment,  Munitions,  and  Computer  Programs. 


USAF  Operational  Major  Command  Functional  Area  Requirement  (FAR), 
SofTech,  Contract  No.  F49642-82-C-0045,  15  December  1982. 
(Unclassified) 


Unit  Combat  Readiness  Reporting  (C-Ratings)  (Unit  Status  and  Identity 
Report  (UNITREP),  RCS:HAF-X00(AR)7112(DD)) ,  AFR  55-15, 

22  November  1982.  (Unclassified) 


*  ee. 


USAFE  Annex  to  USAF  FAR,  SofTech,  Contract  No.  F49642-82-C-0045 ,  20 
August  1982.  (Unclassified) 


*  ff. 


AFIRMS  FAR,  SofTech,  Contract  No.  MDA-903-76-C-0396,  14  March  1980. 
Unclassified) 


*Material  contained  in  references  cc  and  ee  expands  on  that  found  in 
reference  ff. 
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gg.  AFIRMS  Data  Analysis,  SofTech,  15  February  1979.  (Unclassif ied) 

hh.  User's  Viev  of  AFIRMS,  SofTech,  1  November  1978.  (Unclassif ied) 

ii.  AFR  700-9,  Information  Systems  Standards,  15  March  1985. 
(Unclassified) 

jj.  U.S.  Air  Force  Glossary  of  Standardized  Terms,  AFM  11-1,  Vol.  1, 

2  January  1976.  (Unclassified) 

kk.  AFIRMS  Data  Automation  Requirement  (DAR),  Final,  SofTech,  Contract 
No.  MDA-903-76-C-0396 ,  14  March  1980.  (Unclassified) 

11.  JCS  Memorandum  of  Policy  #172,  1  June  1982.  (Unclassified) 

mm.  Military  Airlift  Command  (MAC)  AFIRMS  Requirements  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022,  30  September  1985.  (Unclassified) 

nn.  Analysis  of  Military  Airlift  Command  (MAC)  Capability  Assessment 

Metrics,  SofTech,  Contract  No.  F49642-83-C-0022,  30  September  1985. 
(Unclassified) 

oo.  Strategic  Air  Command  (SAC)  AFIRMS  Requirements  Analysis,  SofTech, 
Contract  No.  F49642-83-C-0022 ,  30  September  1985.  (Unclassified) 

pp.  Analysis  of  Strategic  Air  Command  (SAC)  Capability  Assessment 

Metrics,  SofTech,  Contract  No.  F49642-83-C-0022 ,  30  September  1985. 
(Unclassified) 
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1.3  Terms  and  Abbreviations 


1 .3. 1  Abbreviations  and  Acrony  ms. 


AAC 

AB 

A/C 

AD 

A  DCOM 

ADP 

ADS 

ADTAC 

AF 

AFB 

AFCC 

AFESC 

AFIRMS 

AFLC 

AFM 

AFMPC 

A  FOR  MS 

AFOSP 

AFR 

AFRES 

AFS 

ALC 

ANG 

ARF 

ARMS 

ATC 

ATO 

ATOC 

BLSS 

CAFMS 

CAI 

CAP  Report 


Alaskan  Air  Command 

Air  Base 

Aircraft 

Air  Division 

Air  Defense  Command 

Automated  Data  Processing 

Automated  Data  Systems 

Tactical  Air  Command  -  Air  Defense 

Air  Force 

Air  Force  Base 

Air  Force  Communications  Command 

Air  Force  Engineering  and  Services  Center 

Air  Force  Integrated  Readiness  Measurement  System 

Air  Force  Logistics  Command 

Air  Force  Manual 

Air  Force  Manpower  and  Personnel  Center 

Air  Force  Operations  Resource  Management  System 

Air  Force  Office  of  Security  Police 

Air  Force  Regulation 

Air  Force  Reserve 

Air  Force  Station 

Air  Logistics  Center 

Air  National  Guard 

Air  Reserve  Forces 

Ammunition  Reporting  Management  System  (D078) 
Air  Training  Command 
Air  Tasking  Order 

Allied  Tactical  Operations  Center  (NATO) 

Base  Level  Self-Sufficiency  Spares 
Computer  Aided  Force  Management  System 
Computer-Aided  Instruction 
Capability  Report 


:l 

CAS 

- 

Combat  Ammunition  System 

m 

CBPO 

- 

Consolidated  Base  Personnel  Office 

i 

CFMS 

- 

Combat  Fuels  Management  System 

CINC 

- 

Commander  in  Chief 

COB 

- 

Collocated  Operating  Base 

1 

COMPES 

- 

Contingency  Operations/Mobility  Planning  and  Execution  System 

COMSEC 

- 

Communications  Security 

CONUS 

- 

Continental  United  States 

& 

CRT 

- 

Cathode  Ray  Tube 

4 

CSG 

- 

Combat  Support  Group 

CSMS 

- 

Combat  Supplies  Management  System 

■ 

DAR 

- 

Data  Automation  Request 

§ 

DBMS 

- 

Database  Management  System 

| 

DBS 

- 

Database  Specification 

1 

DO 

- 

Deputy  Commander  for  Operations 

□ 

0078 

- 

ARMS  (Ammunition  Reporting  Management  System) 

3 

DOC 

- 

Designed  Operational  Capability 

r. 

K 

DoD 

- 

Department  of  Defense 

k 

DRD 

- 

Data  Requirements  Document 

1 

DSDO 

- 

Data  Systems  Design  Office 

1 

EIP 

- 

Evolutionary  Implementation  Plan 

emsec 

- 

Emanations  Security 

m 

FAR 

- 

Functional  Area  Requirement 

1 

FD 

- 

Functional  Description 

FEO 

- 

For  Exposition  Only 

:> 

F  MlS 

- 

Force  Management  Information  System 

FOCAS 

- 

Force  Capability  Assessment  System 

M 

FORSCAP 

- 

Force  Capabilities  System 

0 


FRAG 

GLCM 

HOL 

HQ  USAF 
HQ  USAFE 
HTACC 
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Fragmentary  Order 

Ground  Launched  Cruise  Missile 

High  Order  Language 

Headquarters,  United  States  Air  Force 

Headquarters,  United  States  Air  Forces  Europe 

Hardened  Tactical  Air  Control  Center  (PACAF) 
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IDS 

- 

Interface  Design  Specification 

IOC 

- 

Initial  Operational  Capability 

IG 

- 

Inspector  General 

ICAM 

- 

Integrated  Computer-Aided  Manufacturing 

IDEF-l 

- 

ICAM  Definition  Method  One 

1R6 

- 

Is  Referenced  By 

JCS 

- 

Joint  Chiefs  of  Staff 

JCS  MOP  172 

- 

Joint  Chiefs  of  Staff  Memorandum  of  Policy  No.  172,  "Military 
Capability  Reporting,"  1  June  1982 

JOPES 

- 

Joint  Operation  Planning  and  Execution  System 

JOPS 

- 

Joint  Operation  Planning  System 

JRS 

- 

Joint  Reporting  System 

LAN 

- 

Local  Area  Network 

LCMS 

- 

Logistics  Capability  Measurement  System 

LIMFAC 

- 

Limiting  Factor 

LMC 

- 

Logistics  Management  Center 

LOGFAC 

- 

Logistics  Feasibility  Analysis  Capability 

LOG MOD 

- 

Logistics  Module 

LPP 

- 

Learning  Prototype  Phase 

MA 

- 

Deputy  Commander  for  Maintenance 

MAC 

- 

Military  Airlift  Command 

MAJCOM 

- 

Major  Command 

MDS 

- 

Mission  Design  Series 

MEl 

- 

Management  Effectiveness  Inspection 

MOB 

- 

Main  Operating  Base 

MT6F 

- 

Mean  Time  Between  Failure 

NAF 

- 

Numbered  Air  Force 

NCO 

- 

Non-Commissioned  Officer 

OPlan 

- 

Operation  Plan 

OPR 

- 

Office  of  Primary  Responsibility 

OP ST AT 

- 

Operations  Status  Report 

ORI 

- 

Operational  Readiness  Inspection 

OSD 

- 

Office  of  the  Secretary  of  Defense 

OWRM 

_ 

Other  War  Reserve  Materiel 

POL 

- 

Petroleum,  Oil  and  Lubricants 

POM 

- 

Program  Objective  Memorandum 

POS 

- 

Peacetime  Operating  Stock 

RCS 

- 

Reports  Control  Symbol 

RM 

- 

Deputy  Commander  for  Resources 

SAC 

- 

Strategic  Air  Command 

SADT 

- 

Structured  Analysis  Design  Technique 

SAM 

- 

Sustainability  Assessment  Module  (Part  of  WSMIS  formerly  known  as 
CAC) 

SECDEF 

- 

Secretary  of  Defense 

SIT  REP 

- 

Situation  Report 

SQ 

- 

Squadron 

SOA 

- 

Separate  Operating  Agency 

SS 

- 

System  Specification 

TAC 

Tactical  Air  Command 

TACC 

- 

Tactical  Air  Control  Center 

TACNET 

- 

Tactical  Air  Command  Network  ' 

TAF 

- 

Tactical  Air  Forces 

TBD 

-  ■ 

To  Be  Determined 

TFS 

- 

Tactical  Fighter  Squadron 

TFW 

- 

Tactical  Fighter  Wing 

UNIT  REP 

- 

Unit  Status  and  Identity  Report 

USAF 

- 

United  States  Air  Force 

USAFE 

- 

United  States  Air  Forces  Europe 

WIN 

- 

WWMCCS  Intercomputer  Network 

WIS 

- 

WWMCCS  Information  System 

WMP 

- 

War  Mobilization  Plan 

woe 

- 

Wing  Operations  Center 

WSAM 

- 

Weapon  System  Assessment  Model 

WSMIS 

- 

Weapon  System  Management  Information  5ystem 

WWMCCS 

- 

World  Wide  Military  Command  and  Control  System 

SOFTpru 
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1.3.2  Terms  and  Definitions. 


Alert  Sortie 


Aircraft 


Autonomous 

Operation 


Autonomous 

Operation 


Combat 

Capability 


Data 


Decision 


Deployment 


Employment 


A  ground  alert  aircraft  (or  missile)  fully  generated  for 
flight  but  held  on  the  ground  ready  for  an  immediate  launch 
on  its  assigned  mission.  (This  assigns  the  airborne  alert 
missions  into  the  (flying)  sortie  category.) 

A  machine  or  device,  capable  of  atmospheric  flight, 
especially  an  airplane.  Although  a  ballistic  missile  does 
not  fit  this  definition,  a  cruise  missile  does  fit  it. 
However,  AFIRMS  will  not  exclude  ICBMs  from  this 
definition. 

(CENTO,  NATO)  One  mode  of  operation  of  a  unit  in  which  the 
unit  commander  assumes  full  responsibility  for  control  of 
weapons  and  engagement  of  hostile  targets.  This  mode  may 
be  either  directed  by  higher  authority  or  result  from  a 
loss  of  all  means  of  communication.  (JCS  Pub  1) 

(DoD,  IADB)  In  air  defense,  the  mode  of  operation  assumed 
by  a  unit  after  it  has  lost  all  communications  with  higher 
echelon.  The  unit  commander  assumes  full  responsibility 
for  control  of  weapons  and  engagement  of  hostile  targets. 
(JCS  Pub  1) 

The  readiness  status  of  a  unit  to  perform  its  tasked  combat 
mission  and  its  ability  to  sustain  a  required  level  of 
tasking  for  a  specified  number  of  days.  The  terms  "Combat 
Capability"  and  "Readiness  and  Sustainability"  are  used 
interchangeably  throughout  the  AFIRMS  documents. 

(DoD)  A  representation  of  facts,  concepts,  or  instructions 
in  a  formalized  manner  suitable  for  communication, 
interpretation  or  processing  by  humans  or  by  automatic 
means.  Any  representation  such  as  characters  or  analog 
quantities  to  which  meaning  is  or  might  be  assigned.  (JCS 
Pub  1) 

(CENTO,  DoD,  IADB,  NATO)  In  an  estimate  of  the  situation, 
a  clear  and  concise  statement  of  the  line  of  action 
intended  to  be  followed  by  the  commander  as  the  one  most 
favorable  to  the  successful  accomplishment  of  his  mission. 
(JCS  Pub  1) 

(CENTO,  DoD,  IADB,  NATO)  In  a  strategic  sense,  the 
relocation  of  forces  to  desired  areas  of  operation.  (JCS 
Pub  1) 

The  tactical  usage  of  aircraft  in  a  desired  area  of 
operation.  (AFM  11-1) 


CDRL  0023 


1-8/CHG  1 


Flying  Hour(s)  - 

Military 

Capability 


Mission 


Shortfall 


One  or  more  hours  of  operational  flight  by  one  aircraft. 

The  ability  to  achieve  a  specified  wartime  objective  (win  a 
war  or  battle,  destroy  a  target  set).  It  includes  four 
major  components:  force  structure,  modernization, 
readiness,  and  sustainability.  (JCS  MOP  172,  1  June  1982) 

a.  Force  Structure  -  Numbers,  size,  and  composition  of 
the  units  that  comprise  our  defense  forces,  e.g., 
divisions,  ships,  airwings. 

b.  Modernization  -  Technical  sophistication  of  forces, 
units,  weapon  systems,  and  equipments. 

c.  Readiness  -  The  ability  of  forces,  units,  weapon 
systems,  or  equipments  to  deliver  the  outputs  for 
which  they  were  designed  (includes  the  ability  to 
deploy  and  employ  without  unacceptable  delays). 

d.  Sustainability  -  The  "staying  power"  of  our  forces, 
units,  weapon  systems,  and  equipments,  often  measured 
in  numbers  of  days.  (Note:  This  is  the  part  2. 
definition  of  sustainability,  which  is  published 
alphabetically. ) 

a.  The  task  together  with  its  purpose,  thereby  clearly 
indicating  the  action  to  be  taken  and  the  reason 
therefore.  (JCS  Pub  1) 

b.  The  dispatching  of  one  or  more  aircraft  to  accomplish 
one  particular  task  (JCS  Pub  1).  An  aircraft 
dispatched  on  a  mission  may  fly  one  or  more  sorties; 
each  sortie  may  be  one  or  more  hours  in  duration.  In 
addition,  an  aircraft  assigned  to  a  mission  may  not 
fly  but,  instead,  be  on  a  ground  alert  for  the 
mission.  (Added) 

Comment:  The  dispatching  of  an  aircraft  in  b.  above, 
typically  involves  at  least  one  launch  and  recovery 
(i.e.,  AFIRMS  Capability  Assessment).  In  some 
specialized  assessments,  launch  and/or  recovery  are 
not  applicable,  such  as  when  the  mission  is  an  alert 
mission  (no  launch  and  recovery)  or  when  the  weapon 
system  is  a  missile  (no  recovery).  This  AFIRMS  usage 
correlates  to  the  term  "alert  sortie."  The  type  of 
mission  is  included  in  the  sortie  description,  as  in  a 
"CAS  alert  sortie"  or  "SIOP  alert  sortie." 

The  absence  of  forces,  equipment,  personnel,  materiel,  or 
capability — identified  as  a  plan  requirement  —  that  would 
adversely  affect  the  command's  ability  to  accomplish  its 
mission.  (Joint  Deployment  Agency's  Joint  Deployment 
System  Procedures  Manual,  1  January  82) 
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Sortie  (air) 


(CENTO,  NATO)  An  operational  flight  by  one  aircraft. 
(JCS  Pub  1) 


Tasking 


Ton-Mile 


Turnaround 

(Turn) 


(NATO)  The  process  of  translating  the  allocation  into 
orders,  and  passing  these  orders  to  the  units  involved. 

Each  order  normally  contains  sufficient  detailed 
instructions  to  enable  the  executing  agency  to  accomplish 
the  mission  successfully.  (JCS  Pub  1) 

The  movement  of  one  short-ton  (2000  lbs.)  of  cargo  and/or 
passengers  the  distance  of  one  nautical  mile. 

(DoD,  IADB,  NATO)  The  length  of  time  between  arriving  at  a 
point  and  being  ready  to  depart  from  that  point.  It  is 
used  in  this  sense  for  the  loading,  unloading,  refueling 
and  rearming,  where  appropriate,  of  vehicles,  aircraft,  and 
ships.  (JCS  Pub  1) 


1.4  AFIRMS  Synopsis. 

1.4.1  Key  AFIRMS  Concepts.  AFIRMS  is  an  automated,  tasking  based,  capability 
assessment  system.  As  such,  AFIRMS  evaluates  unit  and  force  capability  to 
perform  tasked  missions  based  on  the  availability  of  specific  resources. 


a.  The  conceptual  requirements  for  AFIRMS  are  two-fold: 

(1)  Assessment  of  combat  capability  against  specific  tasking.  The 
user  can  assess  unit/force  combat  capability  against  any  planned 
or  ad  hoc  tasking,  e.g.,  War  Mobilization  Plan  (VMP),  Operation 
Plan  (OPlan),  Fragmentary  Order,  Air  Tasking  Order  (ATO), 
Contingency  Plan,  etc. 

(2)  Assessment  of  combat  capability  based  on  budget  appropriations. 
AFIRMS  provides  a  tool  for  computing  long-term  readiness  and 
sustainability  trends,  spanning  two  to  six  fiscal  years.  This 
tool  permits  comparison  of  readiness  and  sustainability  by 
fiscal  year  and  can  therefore  highlight  the  impact  of 
appropriation  changes.  Thus,  changes  in  funding  are  related  to 
changes  in  force  readiness  and  sustainability.  Also,  senior  Air 
Force  decision  makers  are  supported  during  budget  deliberations 
and  Air  Force  budget  allocations. 
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b.  AFIRMS  implementation  has  two  key  concepts: 

(1)  Integrated  approach  to  tasking  based  capability  assessments. 
AFIRMS  has  two  integrative  dimensions.  First,  all  applicable 
resources  and  their  usage  interactions  are  considered.  For 
example,  in  sortie  capability  assessment,  AFIRMS  evaluates 
capability  in  terms  of  all  four  essential  resource  types 
(aircrew,  aircraft,  munitions,  fuel),  their  interdependencies, 
and  their  generative  components  (such  as  spares  for  aircraft, 
training  qualifications  for  aircrew,  load  crews  for 
munitions , and  hot  pits  for  fuel).  Second,  other  automated 
systems  (such  as  the  Combat  Supplies  Management  System  (CSMS), 
Combat  Fuels  Management  System  (CFMS),  Weapon  System  Management 
Information  System  (WSMIS),  etc.)  outputs  are  integrated  into 
capability  assessment  calculations  through  system  interfaces 
between  those  systems  and  AFIRMS. 

(2)  Data  Quality  Assurance.  Capability  assessment  is  no  better  than 
the  data  upon  which  it  is  based.  Therefore,  AFIRMS  emphasizes  a 
user  orientation  toward  quality  assurance  of  source  data.  Unit 
and  other  data  input  level  users  are  provided  effective  tools 
toaccomplish  their  daily  activities  and  therefore  develop  a 
vested  interest  in  AFIRMS  data  currency  and  validity. 

Capability  assessment  data  can  then  be  extracted  for  use  by 
higher  or  parallel  users  with  maximum  confidence  in  its  validity 


1.4.2  AFIRMS  Functions.  Four  basic  AFIRMS  functions  combine  to  assess 
readiness  capability: 


a.  Translate  Tasking.  As  a  tasking  based  capability  assessment  system, 
tasking  must  be  converted  into  a  standard  format  recognized  by 
AFIRMS.  Tasking  is  defined  in  AFIRMS  to  the  unit  level  and  may 
consist  of  actual,  hypothetical,  standard,  or  contingency  tasking. 

Any  of  these  taskings  can  be  defined  within  specified  WMP  or  OPlan 
constraints,  at  the  option  of  the  user.  Likewise,  the  tasking  may  be 
defined  by  the  user  for  present,  historic  or  future  requirements. 

b.  Define  Resources.  The  resource  definition  function  of  AFIRMS  ensures 
that  information  about  inventory  status  is  available  and  accurate. 
Wherever  possible,  this  data  is  obtained  by  interface  with  other 
functional  systems.  As  with  tasking,  resource  information  can  be 
defined  for  actual,  hypothetical,  standard,  or  contingency 
situations,  either  present,  historic,  or  future. 

c.  Determine  Ability  to  Perform.  Determining  the  force's  ability  to 
perform  is  the  essential  function  of  AFIRMS.  The  tasking  and 
resource  data  are  processed  to  determine  how  much  of  the  specified 
tasking  can  be  accomplished  with  the  resources  available.  Ability  to 
perform  is  evaluated  in  terms  of  the  task  metric  (sorties, etc. )  and 
the  cost  metric  (dollars)  to  provide  readiness/sustainability  and 
dollars  to  readiness  assessments. 
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d. 


Aggregate,  Analyze  and  Present  Data.  Aggregation,  analysis  and 
presentation  ensure  the  proper  grouping  and  display  of  data  to 
provide  useful  information  at  the  unit,  major  command  and  HQ  USAF. 
Aggregation  refers  to  the  creation  of  a  composite  understanding  of 
capability  for  several  units. 
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1.5  AFIRMS  Documentation.  A  set  of  nine  types  of  documents  describes  AFIRMS. 
A  list  of  these  AFIRMS  documents  is  provided  below  along  with  a  short 
description  of  the  particular  aspects  of  AFIRMS  which  are  addressed  by  each 
document. 


a.  Functional  Description  (FD).  The  FD  provides  the  description  of 
AFIRMS  concepts  in  user  terms.  It  is  the  baseline  document  which 
ties  the  AFIRMS  documents  together. 

b.  Economic  Analysis  (EA).  The  EA  states  AFIRMS  estimated  costs.  It 
explains  the  cost  factors  of  AFIRMS  implementation  alternatives  and 
states  the  recommended  alternative. 

c.  Management  Plan.  The  Management  Plan  provides  the  top-level 
integrative  frame  of  reference  for  the  AFIRMS  Program.  The  plan 
focuses  on  the  processes  which  provide  technical  and  administrative 
control  of  AFIRMS.  Key  annexes  to  the  Management  Plan  are  the 
Evolutionary  Implementation  Plan,  the  Configuration  Management 
Support  Plan,  and  the  Systems  Interface  Support  Plan. 

d.  System  Specification.  The  AFIRMS  System  Specification  adds  the 
design  requirements  to  the  functional  concepts  in  the  FD.  It  divides 
the  system  into  subsystems  (HQ  USAF,  HQ  USAFE  (MAJCOM),  and  Wing 
(unit))  and  assigns  functions  required  within  each  subsystem.  The 
system  specification  details  the  overall  architecture,  intersite 
interface  gateways,  processing  logic  flows  and  the  communications 
network  specifications. 

e.  Subsystem  Specifications.  There  are  three  AFIRMS  subsystem 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
the  Wing  (unit/squadron).  Subsystem  specifications  detail  the 
specific  design  and/or  performance  requirements  of  the  system  at  that 
level.  Design  details  cover  the  architecture,  required  functions, 
the  functional  users,  intrasite  interface  gateways,  and  applicable 
processing  logic  flows. 

f.  Database  Specifications.  There  are  three  AFIRMS  database 
specifications:  HQ  USAF,  HQ  USAFE  (MAJCOM/numbered  Air  Force),  and 
Wing  (unit/squadron).  These  specif ications  describe  the  database 
architecture,  size,  and  content,  as  well  as  logical  data 
relationships  for  the  functions  performed  at  each  of  the  AFIRMS 
levels . 

g.  Data  Requirements  Document  (DRD).  The  DRD  identifies,  categorizes, 
and  groups  the  generic  types  of  used  in  AFIRMS.  It  also  defines  each 
type  of  AFIRMS  data  element  (attribute  class). 

h.  Product  Descriptions  (PDs).  The  PDs  visually  portray  the  products 
which  implement  the  AFIRMS  functions  as  input  and  output  tools. 
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i.  Transform  and  Model  Descriptions.  The  Transform  and  Model  /vVi 

Descriptions  Document  defines  how  AFIRMS  calculates  the  output  data  ^5* 

from  the  input  data.  Specific  algorithmic  calculations  are  provided. 

Logical  groups  of  algorithms  forming  AFIRMS  models  and  transforms  are 
described. 
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SECTION  2.  SYSTEM  SUMMARY 

This  system  summary  provides  a  general  description  of  the  background  of 
AFIRMS,  system  objectives,  current  relevant  methods/procedures,  AFIRMS 
methods,  and  their  resulting  implementation  impacts. 

First  we  expand  on  the  definition  of  AFIRMS.  AFIRMS  is  an  automated 
system  which: 

a.  Assesses  and  projects  combat  capability  by  realistically  estimating 
each  unit,  theatre,  and  force's  ability  to  perform  specific  taskings; 
basing  all  estimates  on  an  integration  of  a  variety  of  resources 
on-hand  and  on  achievable  plans  for  resupply. 

b.  Uses  assessments  of  combat  capability  as  a  basis  for  decision  support 
in  the  budget  process,  linking  dollars  to  readiness. 

Resources  considered  include  aircraft  (the  number  mission  ready,  available 
reparable  spares,  maintenance  support),  aircrews,  munitions  (whole-up  rounds, 
components,  load  crews),  and  fuel. 

The  taskings  considered  are  not  limited.  For  example,  they  might  be  the 
War  Mobilization  Plan  (WMP),  ad  hoc  crisis  plan,  or  a  what-if  plan. 

The  ability  to  perform  is  measured  in  units  of  measure  suitable  to  the 
mission/tasking  description.  For  example,  ton-miles  apply  only  to  the  airlift 
mission.  Additionally,  alert  sorties  apply  only  to  those  missions  that 
generate  but  do  not  launch,  and  sorties  and  flying  hours  apply  only  to  those 
missions  that  do  launch  and  recover.  On  the  other  hand,  the  "mission"  metric 
applies  to  all  of  the  mission  types  Air  Force-wide,  i.e.,  the  Tactical  Air 
Forces  (TAC,  USAFE,  PACAF,  AAC),  Strategic  Air  Command  (SAC),  and  Military  Air 
Command  (MAC). 
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The  primary  reason  for  basing  AFIRMS  on  the  ability  to  perform  specific 
tasking  is  to  provide  all  levels  of  command  with  a  measurement  directly 
related  to  the  job  to  be  done.  Integration  of  data  is  vital  to  this 
measurement . 

These  factors  are  examined  in  greater  detail  in  the  remainder  of  this 
document . 
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2.1.1  The  Need .  The  question  "are  we  ready?"  has  many  dimensions. 

Exercises,  inspections,  evaluations,  and  other  traditional  techniques  not  only 
train  a  force,  but  inform  the  commander  of  the  readiness  of  that  force.  The 
need  for  some  measure  of  readiness  has  been  recognized  since  the  C-rating 
readiness  measurement  system  was  instituted  in  1950.  None  have  proven  totally 
sufficient . 

In  1976,  the  Air  Force  Chief  of  Staff  developed  Constant  Readiness  Tasking 
which  tasked  the  Air  Force  to  "...  develop  responsive  means  of  assessing  and 
reporting  combat  capability."  The  AFIRMS  concept  began  with  that  tasking  and 
has  continued  to  evolve.  Congress,  through  the  FY78  Defense  Authorization 
Act,  tasked  the  Secretary  of  Defense  to  project  the  effect  of  appropriations 
on  materiel  readiness,  i.e.,  "dollars  to  readiness."  Defense  Guidance  since 
that  time  has  directed  the  Services  to  develop  methods  to  model  the 
relationship  of  force  readiness  with  associated  manpower  and  dollar  resources. 

Readiness  Assessment  is  needed: 

a.  At  the  Office  of  the  Secretary  of  Defense  (OSD)  and  Joint  Chiefs  of 
Staff  (JCS)  levels  —  to  respond  to  questions  impacting  national 
policy;  to  guide  budget  development;  to  assign  forces;  to  apportion 
resources . 

b.  At  HQ  USAF  level  —  to  guide  budget  development;  to  guide  force 
assignment;  to  apportion  and  distribute  resources;  to  respond  during 
crisis. 

c.  At  the  MAJCOM  and  NAF  levels  —  to  assist  in  force  assignment; 
distribution  of  resources;  and  evaluation  of  tasking  validity. 

d.  At  unit  level  —  to  direct  forces;  to  best  use  resources;  to  indicate 
training  needs;  to  accomplish  the  unit's  tasked  mission. 

2.1.2  Related  Efforts.  Efforts  to  meet  these  needs  in  increasingly 
sophisticated  ways  have  been  underway  not  only  in  the  Air  Force  but  throughout 
the  DoD.  The  realization  of  the  need  for  a  more  meaningful  expression  of  Air 
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Force  capabilities  led  to  the  development  of  C-ratings  in  the  mid-1950s.  The 
C-ratings,  in  updated  form,  are  in  use  today  as  part  of  the  JCS  Unit  Status 
and  Identity  Report  (UNITREP)  System. 
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The  AFIRMS  effort  and  many  others  address  one  or  more  aspects  of  readiness  and 
sustainability.  These  include:  3CS  MOP  172,  Military  Capability  Reporting;  Operational 
Readiness  Inspections  (ORIs),  Management  Effectiveness  Inspections  (MEIs);  Exercises; 
Logistics  initiatives  including  the  Weapon  System  Management  Information  System 
(WSMIS),  Logistics  Capability  Measurement  System  (LCMS),  Ammunition  Reporting 
Management  System  (ARMS)  (D078),  Force  Capability  Assessment  System  (FOCAS), 
Logistics  Feasibility  Analysis  Capability  (LOGFAC),  Air  Force  Operations  Resource 
Management  System  (AFORMS),  and  JCS  initiatives,  especially  the  World  Wide  Military 
Command  and  Control  (WWMCCS)  Information  System  (WIS)  and  the  Joint  Operations 
Planning  and  Execution  System  (JOPES).  Among  these  efforts,  the  AFIRMS  approach  is 
unique  in  the  two  types  of  integration  required  for  AFIRMS  capability  assessments.  These 
two  types  of  integration  are: 

a.  AFIRMS  integrates  key  capability  factors  into  one  assessment.  AFIRMS 
integrates  a  variety  of  factors  and  assesses  unit  capability  to  perform  a  specific 
task  by  using  a  common  unit  of  measure  such  as  sorties,  flying  hours,  ton-miles, 
etc.  In  this  way,  users  at  all  levels  will  be  able  to  focus  on  what  a  unit  or  force 
is  ready  to  do  as  well  as  the  shortfalls  which  actually  limit  performance. 

b.  AFIRMS  integrates  selected  data  from  a  number  of  systems  to  prevent 
duplication  of  collection  efforts.  Relevant  data  from  all  other  available 
systems  is  being  reviewed  and,  where  needed  and  feasible,  used  as  source  data 
for  AFIRMS.  This  reduces  redundant  and  contradictory  data  records  and 
duplication  of  reporting  efforts. 

AFIRMS  provides  other  unique  advantages  in  the  type  of  assessments  provided  and  in 
the  usefulness  of  the  system  to  readiness  analysts: 

a.  Ad  hoc  query  capability. 

b.  Decision  support  via  what-if  capability. 

c.  Use  in  commanders  judgment  and  potential  work-arounds. 

d.  Identifying  Limiting  Factors  (LIMFACS)  and  their  respective  impacts  on 
readiness. 

2.1.3  Terminology.  Terms  of  particular  importance  in  defining  the  purpose  of  AFIRMS 
include  Military  Capability  and  its  components:  Force  Structure,  Modernization, 
Readiness,  and  Sustainability  (see  Section  1.3.2). 


As  already  noted,  AFIRMS  is  designed  to  provide  ail  levels  of  command  with 
information  about  readiness  and,  through  extensions  of  the  readiness  calculations, 
projections  of  sustainability. 

SC 
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Sustainability  is  closely  related  to  readiness.  Any  system  designed  to 
answer  the  question  "how  many  sorties  can  we  fly  today?"  will  surely  be  asked 

"how  many  sorties  can  we  fly  tomorrow?"  .  "oh,  and  the  next  day?"  The 

point  at  which  the  discussion  shifts  from  readiness  to  sustainability  is  not, 
and  probably  cannot  be,  delineated.  As  an  example,  the  Air  Force  IfNITREP 
definition  of  readiness  includes  the  first  30  days  of  combat. 

Because  of  the  need  to  address  dollars  to  readiness,  and  because  readiness 
is  so  closely  tied  to  sustainability,  AFIRMS  will  consider  areas  of  military 
capability  beyond  the  narrowest  definition  of  readiness. 

2.2  Objectives.  The  AFIRMS  Program  objectives  include  action  to  be 
accomplished,  a  method  for  the  accomplishment,  and  criteria  to  measure  the 
accomplishment.  They  are  defined  as  follows: 


a.  Action.  Assess  readiness  and  sustained  ability  to  accomplish 
specific  tasking.  Use  assessments  to  support  "what-if"  or 
"trade-off"  studies  such  as: 

(1)  Relating  changes  in  funding  to  changes  in  force  readiness  and 
sustainability  for  budgetary  exercises. 


(2)  Assessing  alternative  proposals  for  allocation  of  resources  or 
assignments  of  tasking. 

b.  Method . 

(1)  Express  measurement  in  terms  closely  related  to  taskings  such  as 
mission. 


(2)  Provide  alternate  views  for  functional  analysis  and  use  of  the 
capability  assessments  with  additional  metrics  such  as  dollars, 
sorties,  alert  sorties,  flying  hours,  and  ton-miles.  (Dollars 
is  the  obvious  metric  for  budgetary  analysis  purposes.  Sorties, 
alert  sorties,  and  flying  hours  may  be  useful  as  a  readiness 
metric  to  supplement  the  UNITREP  C-rating  system,  while 
ton-miles  would  be  pertinent  to  airlift  planning  and 
programming. ) 


(3)  Obtain  reliable  data  from  other  systems  or  by  providing 

incentives  to  human  data  sources  in  the  form  of  products  which 
serve  day  to  day  functions  other  than  capability  assessment. 
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Cri teria.  To  be  successful,  AFIRMS  must: 

(1)  Operate  with  historic,  current,  forecast,  or  hypothetical  data. 

(2)  Function  at  unit,  NAF,  MAJCOM,  and  HQ  USAF  levels. 

(3)  Respond  to  orders  such  as  UMP,  Operation  Plan  (OPlan),  or 
specific  fragmentary  tasking. 

(4)  Be  useful  in  peacetime,  crisis,  or  exercise. 

(5)  Apply  to  all  weapon  systems  and  missions. 
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2.2.1  Sub-objectives  of  the  Functioning  AFIRMS.  The  primary  objective  is  composed  of  a 
number  of  sub-objectives: 


a.  To  present  clearly  and  concisely  the  readiness  information  needed  by 
commanders  and  other  users  at  all  command  levels  in  peacetime,  crisis,  and  war 

(to  the  extent  that  AFIRMS  is  survivable).  | 

b.  To  aid  and  expedite  human  calculation  of  the  readiness  of  a  unit  to  meet  the 
tasking  imposed  upon  it  in  real  situations  using  a  given  set  of  resources. 

c.  To  translate  tasking  so  that  it  can  be  used  in  measuring  ability  to  perform,  i.e., 
convert  tasking  to  aircraft,  Petroleum,  Oil  and  Lubricants  (POL),  munitions, 
crews,  etc.,  required  to  accomplish  that  tasking. 

d.  To  calculate  force  readiness  and  sustainability  with  a  credibility  sufficient  to 
permit  what-if  exercises  in  support  of  budget  deliberations  and  resource 
allocation  planning. 

e.  To  compute  long-term  readiness  and  sustainability  trends,  spanning  two  to  five 
fiscal  years,  which  compare  readiness  and  sustainability  by  fiscal  year  and 
connect  the  impacts  of  appropriations  by  fiscal  year. 

f.  To  aggregate  readiness  and  sustainability  and  the  factors  which  impact 
readiness  and  sustainability  over  successively  higher  levels  of  command. 

g.  To  track,  recognize,  report,  and  project  trends  in  readiness  and  sustainability. 

h.  To  take  maximum  advantage  of  data  possessed  by  existing  and  developing 
systems  dealing  with  assessment,  logistics,  personnel,  etc. 

i.  To  obtain  local  data  elements  on  a  timely  and  accurate  basis,  while  presenting 
minimum  inconvenience  to  the  collector. 

j.  To  give  the  data  collectors  some  benefit  of  the  information  they  provide;  that 
is,  to  reward  accurate  and  timely  input  with  output  of  use  to  those  responsible 
for  the  input. 

k.  To  permit  recalculation  of  historic  readiness  values  on  the  basis  of  new  or 
revised  standards.  This  capacity  is  needed  for  valid  comparisons  between 
current  and  past  levels  of  readiness  and  sustainability.  To  permit  such 
calculations,  periodic  archiving  of  "raw"  resource  data  is  required. 


2.3  Existing  Methods  and  Procedures.  There  are  many  systems  which,  in  one  way  or 
another,  relate  to  capability.  This  section  arbitrarily  groups  those  systems  into 
traditional  systems,  inventory  systems,  and  rating  systems.  Each  group  is  examined  to  the 
level  of  detail  necessary  to  show  why  it  does  not  meet  the  needs  addressed  by  AFIRMS. 
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2.3.1  Traditional  Systems.  The  category  name  "traditional"  reflects  physical  observation, 
not  obsolescence.  ORis,  MEls,  and  readiness  exercises  all  test  capability  in  an  important 
and  fundamental  way.  If,  however,  an  answer  is  needed  about  the  readiness  or 
sustainability  of  a  specific  unit  today,  it  is  not  feasible  to  conduct  an  ad  hoc  exercise  or 
inspection  to  get  that  answer.  Aggregating  the  results  of  such  reviews  to  assess  the 
readiness  or  sustainability  of  a  unit  or  force  at  a  given  time  is  not  feasible. 

2.3.2  Inventory  Systems.  We  use  "inventory  systems"  in  the  broad  sense  of  anything 
which  tracks  the  supply  of  a  resource  on-hand  at  a  unit.  This  supply  information  is 
fundamental  to  two  kinds  of  functions:  measuring  capability  and  managing  the  supply  of 
the  resource. 

Inventory  systems  which  support  the  resource  management  functions  include 
AFORMS  which  manages  aircrew  resources  and  their  training  requirements,  and  various 
logistics  systems  which  manage  munitions,  POL,  etc.  Many  of  these  inventory  systems 
have  been,  or  are  being,  automated.  It  would  be  easy  to  assume  that  these  inventory 
systems  hold  the  key  to  the  function  of  measuring  capability. 

If  capability  consisted  of  the  sum  of  our  supplies  of  munitions,  spares,  personnel, 
training,  etc.,  the  systems  supporting  the  management  of  each  resource  could  report  how 
much  of  that  resource  is  available  in  total  and,  by  summing  all  those  totals,  the  capability 
of  the  Air  Force  could  be  calculated. 

In  practice,  the  integrated  view  of  capability  begins  at  the  squadron  level.  Not  only 
is  capability  information  needed  at  every  level  of  command,  but  the  data  summaries 
provided  by  the  squadron  level  will  increase  the  accuracy  of  assessments  since  macro 
calculations  sometimes  distort  the  readiness  pictures.  The  aggregation  mechanisms  must 
prevent  distortion  of  macro  calculations.  An  example  of  this  distortion  occurs  if  one 
squadron  short  of  aircrews  and  one  squadron  short  of  spares  is  counted  as  one  squadron 
without  shortages.  Both  squadrons  lack  the  ability  to  perform.  This  understanding  of 
ability  to  perform  can  be  reached  only  from  a  bottom-to-top  approach.  AFIRMS  will  look 
at  multiple  resources,  consider  their  interrelationships,  and  provide  a  measure  of  what 
each  unit  is  able  to  do.  At  the  MAJCOM  level,  wing  readiness  and  sustainability  will  be 
rolled  up  and  additional  theatre  factors  added.  MAJCOM  theatre  assessments  will  go  to 
HQ  USAF  where  other  relevant  factors  will  be  merged  to  achieve  an  overall  force 
capability  picture. 
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2.3.3  Readiness  Rating  Systems.  The  term  "readiness  rating  systems"  refers  to  systems 
^>3  designed  with  the  measurement  of  readiness  as  a  specific  objective.  The  UNITREP 

C-rating  System  exemplifies  this  type  of  system.  Under  UNITREP,  each  unit  is  required 
to  report  resource  fill  against  four  measured  areas:  personnel,  training,  equipment  and 
supplies  on-hand,  and  equipment  readiness.  In  the  simplest  case,  the  percent  fill  of  the 
amount  of  authorized  resources  for  the  unit's  mission  determines  the  C-rating  (i.e.,  Cl, 
C2,  C3,  C4)  of  that  measured  area.  In  practice,  the  ratings  are  more  complex  than  in  this 
simplest  case,  but  follow  the  same  concept  of  fully,  substantially,  partially,  or  not  combat 
ready. 


The  unit's  overall  rating  is  the  lowest  rating  of  any  of  its  four  measured  areas,  unless, 
in  the  judgment  of  the  commander,  the  overall  rating  is  changed  to  reflect  more 
accurately  the  readiness  of  the  unit.  The  commander's  subjective  judgment  may  reflect 
elements  such  as  shortages  of  critical  spares  or  skills  which  were  not  highlighted  by  the 
resource  fill  percentages  of  the  four  measured  areas.  The  basis  of  changes  made  by  the 
commander  are  reported  in  plain  text  remarks. 


Aggregation  of  unit  readiness  to  higher  levels  is  performed  in  each  of  the  four 
measured  areas  and  in  the  overall  ratings.  Aggregating  is  reported  in  terms  of  the 
percentage  of  units  reporting  each  of  the  C  levels  and  is  done  by  weapon  system, 
MA3COM,  and  function. 


Media  used  include  punched  cards  and  magnetic  tapes.  Additionally,  considerable 
manual  effort  is  required  to  derive  the  Cl,  C2,  C3,  and  C4  ratings  for  each  unit. 

This  system  provides  insight  into  readiness  and  is  used  heavily  at  HQ  USAF. 

However,  it  is  being  asked  to  do  many  things  for  which  it  was  not  designed.  Consequently, 
its  users  suffer  because: 


a. 

The  system  does  not  state  what  the  unit  is  actually  ready  to  do,  e.g.,  number  of 
sorties,  or  if  it  has  capabilities  in  areas  other  than  its  primary  Designed 

Operational  Capability  (DOC). 

b. 

The  system  looks  at  the  four  measured  areas  as  though  they  were  independent 
rather  than  part  of  an  integrated  whole. 

c. 

The  system  looks  at  unit  assets  only  and  does  not  consider  the  impact  of  fuel, 
munitions,  and  other  combat  support  on  the  readiness  of  the  combat  unit. 

d. 

The  system  depends  heavily  on  human  assimilation  of  the  commander's  plain 

> 

text  comments  at  the  MAJCOM  and  HQ  USAF  level. 
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e.  The  system  lacks  flexibility. 


f.  The  system  has  no  what-if  capabilities. 

g.  The  wing,  which  must  provide  all  of  the  information  on  which  the  system  is 
based,  receives  no  direct  benefits  from  the  system. 

h.  There  is  no  projection  capability. 

i.  The  system  is  not  continuous;  updates  are  reported  on  an  exception  basis  and 
information  can  be  one  to  30  days  old. 

j.  Changes  in  capability  over  time  cannot  currently  be  evaluated. 

k.  The  impact  of  changes  in  Air  Force  budgets  cannot  be  forecast. 


2.3.4  Existing  Information  Flows.  Under  current  practice,  many  data  flows  carry 
information  relevant  to  readiness  through  various  Air  Force  channels.  None,  however, 
provides  the  explicit  focused  data  actually  required  to  provide  all  levels  of  command  with 
a  much  needed  planning  and  monitoring  tool.  The  types  of  flow  include: 

a.  UNITREP  reports; 

b.  Commander  in  Chief  (CINC)  situation  reports  (SITREPs); 

c.  Functional  area  reports;  and, 

d.  Inspector  General  (IG)  inspection  (ORI  and  MEI)  reports. 

Outputs  from  all  of  these  sources  of  data  are  currently  processed  by  staff  personnel  at 
MAJCOMs  and  HQ  USAF.  Figure  2-1  represents  this  data  flow. 

It  is  difficult  to  provide  current,  integrated  readiness/capability  assessments  based  on 
this  mix  of  diverse,  independent,  and  generally  infrequent  inputs.  The  flows  of  the  four 
types  of  data  differ.  The  following  simplified  drawings  of  Figures  2-2,  2-3,  2-4,  and  2-5 
indicate  their  basic  structure.  Note  that  support  unit  reports  reach  HQ  USAF  through 
several  possible  routes  and  are  carried  by  a  number  of  channels. 
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Figure  2-2.  Flow  of  Information  by  Functional  Areas 
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Figure  2-3.  Flow  of  UNITREP  Information 
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2.4  Proposed  Methods  and  Procedures.  At  the  inception  of  AFIRMS  in  1978,  the  "R" 
stood  for  a  definition  of  readiness  which  today  more  closely  corresponds  to  the  1982  JCS 
definition  of  capability.  Hence,  the  readiness  assessed  by  AFIRMS  addresses  wartime 
objectives  as  tasking,  be  it  WMP,  OPlan,  or  ATO.  AFIRMS  considers  force  structure  with 
respect  to  numbers  of  aircraft,  aircrews,  etc.,  and  their  respective  impact  on  readiness. 
Modernization  is  a  consideration  to  the  extent  that  AFIRMS  will  consider  tasking  match 
ups,  e.g.,  aircraft  performance  factors  or  preferred  munitions.  The  primary  focus  of 
AFIRMS  is  on  the  ability  of  forces,  units,  weapon  systems  to  initiate  and  sustain 
operations  against  specified  tasking.  A  detailed  account  of  readiness  assessment 
computations  is  presented  in  the  Transform  and  Model  Descriptions  document.  An 
operational  AFIRMS  readiness  assessment  methodology  includes: 

a.  Incorporation  of  either  objective  or  subjective  evaluations. 

(1)  Objective  measurements  against  standard  parameters. 

(2)  Subjective  measurements  against  parameters  varied  to  reflect 
commander's  judgment. 

(3)  Incorporation  of  commander's  judgment  as  comments  to  accompany  either 
objective  or  subjective  measures. 

b.  CINC's/CINC’s  staff  judgment/policy  reflected  in  MA3COM  inputs. 

c.  CSAF  judgment/policy  reflected  in  HQ  USAF  inputs. 

d.  Other  systems  which  will  feed  AFIRMS  readiness  data  and/or  assessments. 

e.  Ability  to  perform  what-if  exercises  in  support  of  dollars  to  readiness 
assessments,  force  assignments,  and  resource  transfer  decisions. 

f.  Decision  support  techniques  at  all  levels  designed  to  provide  high  visual  impact 
for  the  important  (often  exception  type)  data.  These  techniques  allow  the  user 
to  move  between  high  level  summarized  data  and  detailed  data  within  the  same 
subject  matter,  as  authorized  for  access  at  each  echelon. 

g.  Capability  "products"  that  are  continuously  available  to  decision-makers  via 
graphic  displays  and  hardcopy.  These  products  are  based  upon  the  most  current 
data. 

2.4.1  Summary  of  Improvements.  This  section  reviews  the  characteristics  of  the  AFIRMS 
system,  the  benefits  they  provide,  and  the  overall  flow  of  the  AFIRMS  system. 


2  A.  1.1  Exploitation  of  Automation.  The  most  readily  observable  fact  of  AFIRMS  is  that 
it  is  a  highly  automated  system.  This  means  that  operational  AFIRMS  can  provide: 


a.  Storage,  updating,  and  retrieval  of  large  volumes  o'  data  swiftly  under  the 
control  of  careful  editing  procedures,  and  in  concert  with  other  systems. 

b.  Data  transmission  for  quickly  reporting  readiness  and  sustainability  factors  and 
assessments  within  and  between  command  levels. 

c.  Swift  computation  using  volumes  of  data  to  derive  capability  assessments. 

d.  Graphics  for  concise,  easily  understandable  presentation  of  data  which  enables 
decision-makers  to  grasp  complex  capability  issues  quickly. 

e.  Automatic  monitoring  of  selected  database  entities.  If  certain  attributes  take 
on  values  outside  of  predefined  ranges,  alarms  can  automatically  be  raised. 


2 A.  1.2  Current,  Accurate  Data.  Based  on  the  automation  just  described,  AFIRMS  uses 
four  main  approaches  to  ensuring  the  accuracy  and  the  currency  of  the  data.  These  are: 

a.  Provide  benefits  to  the  organizations  which  input  data.  If  the  unit  inputs  data 
and  receives  benefits  from  the  system  in  peace  and  crisis,  then  the  unit  will  be 
motivated  to  ensure  that  data  input  is  current  and  accurate. 

b.  Simplify  data  input  by  using  simple  devices  and  by  grouping  inputs.  For 
example,  a  bar  code  reader  is  a  candidate  device  for  entering  a  complex 
identification  number  that  might  be  subject  to  error  if  entered  via  keyboard. 

c.  Use  automated  edit  checks  as  well  as  checks  for  the  reasonableness  of  input 
data  against  stored  parametric  values. 

d.  Obtain,  edit,  and  incorporate  data  and/or  assessments  from  other  automated 
systems.  The  plan  to  obtain  data  is  tailored  in  several  aspects  to  the  specifics 
of  each  system.  These  aspects  include: 

(1)  Relevance  of  available  data. 

(2)  Timeliness  of  data  available  at  all  levels. 

(3)  The  types  of  interfaces  required: 

(a)  Software  required, 

(b)  Impact  on  hardware  platform  selection, 

(c)  Types  of  data  flow,  such  as  continuous,  periodic  or  on-demand. 


2.4. 1.3  Measure  by  Ability  to  Perform.  The  AFIRMS  wing  level  readiness 
assessment  for  fighter/reconnaissance  units  is  based  on  the  number  of  missions 
the  wing  is  tasked  to  produce  in  a  given  time  period.  This  measure  is 
appropriate  because  the  AFIRMS  mission  (e.g.,  sorties)  is  the  elemental 
product  produced  by  the  ving/squadron.  It  is  also  the  vehicle  b;  which  a 
wing/squadron  is  tasked  by  a  higher  authority.  Using  the  mission  as  a  unit  of 
measurement,  the  wing's/squadron's  ability  to  accomplish  a  task  can  be 
assessed  in  terms  common  to  the  ving/squadron  task,  e.g.,  a  fighter  wing  can 
produce  130  (in  the  mission-sortie  sense)  sorties  out  of  the  144  sorties  it 
was  tasked  to  fly  (the  mission  is  decomposed  into  the  component  sorties  and 
flying  hours  for  the  assessment  computations). 

The  use  of  a  measurement  scale  based  on  missions  provides  the  commander  a 
decision  support  tool  which: 

a.  Assesses  the  unit  capability  to  accomplish  the  tasking  within  the 
response  time  with  available  resources. 

b.  Lists  limiting  resources. 

c.  Provides  assessment  of  the  impact  of  proposed  work-arounds  on 
readiness  and  sustainability. 

The  primary  metric  (mission)  provides  a  common  Air  Force-wide  vehicle  to 
aggregate  the  diverse  units,  weapon  systems,  and  missions/tasks  into  a  total 
major  command  and  Air  Force  capability  assessment.  The  use  of  alternate 
metrics  (sorties,  alert  sorties,  flying  hours,  dollars,  ton-miles),  each  of 
which  can  be  derived  from  the  primary  metric  (mission),  provides  the 
functional  staffs  with  the  functional  views  necessary  for  analyzing  unit 
capability  measurements. 


The  tasking  used  in  these  assessments  may  be  either  standard  (such  as  the 
VMP-5)  or  ad  hoc  (either  real  or  hypothetical).  In  either  event  it  will  be 
necessary  to  use  an  AFIRMS  function  called  "Translate  Tasking"  to  represent 
the  tasking  in  a  format  and  content  which  is  standard  to  AFIRMS.  For  standard 
taskings,  this  content  will  be  established  once,  and  stored  in  the  AFIRMS 
database  for  repeated  reference.  For  ad  hoc  taskings,  Air  Force  personnel 
will  be  prompted  by  AFIRMS  to  supply  any  information  which  AFIRMS  itself 
cannot  supply  by  table  look-ups. 
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A  wing/squadron's  readiness  to  perform  a  task  will  be  established  on  the  basis  of 
current  (and/or  projected)  resources  without  reference  to  pre-established  resource 
authorization  and  wiil  not  be  limited  to  a  unit's  primary  mission. 

2.4. 1.4  What-If  Exercises.  Because  AFIRMS  is  an  automated  system,  and  because  of  the 
unit  used  to  measure  readiness  and  sustainability,  it  is  possible  to  test  hypothetical 
situations  to  determine  the  effect  on  capability. 

a.  What  if  a  portion  of  a  munition  is  reallocated  from  MAJCOM  A  to  MAJCOM  B? 

b.  What  if  some  extra  funds  are  spent  on  training  in  FY88? 

c.  What  if  this  task  is  reassigned  from  Wing  XXX  to  Wing  YYY? 

The  capability  for  what-if  exercises  is  provided  through  data  replication  in  the  AFIRMS 
database  in  the  following  way.  When  an  AFIRMS  user  decides  to  perform  a  what-if  exercise, 
he  is  assigned  his  own  copy  of  the  part  of  the  standard  AFIRMS  database  that: 

a.  He  has  access  to,  based  upon  his  logon  privileges. 

b.  Relate  to  his  area  of  inquiry. 

c.  Will  change  under  the  conditions  specified. 

When  first  made  available  to  the  user,  this  copy  of  the  database  is  identical  in  content 
and  value  to  the  relevant  portions  of  the  current  AFIRMS  database.  The  determination  as  to 
whether  the  copy  is  virtual,  physical,  or  a  combination  will  be  made  based  on  sizing 
considerations  related  to  the  what-if  exercise.  The  Database  Specifications  contain 
database  sizing  information  and  fully  specify  assumptions  related  to  instances  of  databases 
to  be  supported  operationally. 

As  the  what-if  exercise  progresses,  the  user  will  make  changes  to  the  what-if  database 
allowing  him  to  address  the  kinds  of  hypothetical  questions  identified  above.  Following  the 
conclusion  of  a  what-if  exercise  session,  the  user  has  the  option  of  storing  his  what-if 
database  for  subsequent  use  (normally  off-line)  or  simply  deleting  it.  The  number  of  what-if 
exercises  in  process  at  one  time  is  defined  by  the  System  and  Subsystem  Specifications. 


2.4. 1.3  Reporting.  In  each  of  the  areas  just  discussed,  the  result  is  a  report  to  a  user.  To 
gain  the  full  benefits  of  AFIRMS,  users  must  be  provided  with  information  displays  which: 


a.  Present  what  a  unit  or  force  is  ready  to  accomplish  under  a  given  tasking. 

b.  Highlights  out-of-limits  (critical)  conditions. 

c.  Identify  the  shortfalls  limiting  unit  or  force  readiness  and  sustainability. 

d.  Provide  a  connection  from  dollars-in,  to  readiness-out  for  budget  exercises. 

e.  Make  trade-off/resource  reallocations,  or  what-ifs  before  initiating  actions  to 
correct  shortfalls. 

f.  Relate  outputs  in  which  the  user  can  ask  for  more  details  about  an  area  of 
concern  ("Munitions  are  a  problem;  show  me  each  kind  of  munition 
separately."),  or  ask  for  summary  data  ("POL  is  a  problem;  show  me  its  status 
alongside  those  of  munitions,  aircraft,  and  aircrew."). 

g.  Exploit  the  advantages  of  color  to  present  complex  readiness  concepts  in  a 
graphic  form  which  focuses  user  attention  on  the  central  issues. 

h.  Complement  and/or  assist  with  UNITREP  calculations. 


2.4. 1.6  Proposed  AFIRMS  Information  Flow.  The  proposed  AFIRMS  information  flow  is 
shown  in  Figure  2-6.  Squadrons  are  linked  hierarchically  to  a  wing,  which  is  linked 
hierarchically  to  a  MAJCOM,  which  in  turn  is  linked  to  HQ  USAF.  Numbered  Air  Forces 
(NAFs)  are  being  considered  MA3COM-like  operation  centers  in  the  AFIRMS 
architecture.  The  role  of  the  NAFs,  and  consequently  the  AFIRMS  functionality  required 
at  the  NAFs,  will  vary  by  MA3COM  depending  on  the  MAJCOM  use/tasking  of  the  NAFs. 
Adjuncts  to  the  hierarchy  are  the  MA3COM  interfaces,  which,  through  WWMCCS,  share 
information  among  themselves  (AFIRMS  may  require  sharing  of  information  at  the 
MAJCOM  level).  The  flows  identified  are  hierarchical  in  nature.  Since  AFIRMS  is  a 
decision  support  system  and  not  a  command  and  control  system,  information  flow  is 
primarily  bottom  to  top,  although  top  to  bottom  requests  for  data  are  not  excluded. 
Specific  information  flow  requirements  vary  by  MAJCOM  as  specified  in  the  System  and 
Subsystem  specifications. 


The  right  hand  side  of  Figure  2-6  identifies  some  of  the  systems  with  which  AFIRMS 
may  interface  at  HQ  USAF,  MAJCOM,  and  wing  levels.  The  extent  of  the  interface,  i.e., 
physical  hookup,  exchange  of  diskettes,  exchange  of  tapes,  etc.,  is  yet  to  be  determined. 
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The  squadrons  currently  supply  data  to  a  number  of  systems  (or  will  supply  data  when 
the  system  becomes  operational,  e.g.,  Combat  Ammunition  System  (CAS)),  as  is  shown  by 
the  connection  from  the  squadrons  to  these  systems.  Another  view  of  the  AFIRMS 
information  flow  appears  in  Section  2.4.3.2. 


2.4.2  Summary  of  Impacts.  This  section  examines  three  types  of  impacts  which  AFIRMS 
is  expected  to  have.  The  impacts  examined  are  discussed  in  terms  of  three  questions: 

a.  Does  the  use  of  AFIRMS  imply  any  changes  in  organization  or  manning? 

b.  Does  the  use  of  AFIRMS  imply  any  changes  in  how  things  are  done,  by  whom 
they  are  done,  how  often  they  are  done,  or  when  they  are  done?  How  do  people 
interface  with  the  computer? 

c.  What  user  efforts  are  required  to  prepare  for  and  permit  deployment  of 
operational  AFIRMS;  what  training,  what  advance  data  storage,  what  testing, 
what  parallel  operation? 

2.4.2. 1  User  Organizational  Impacts.  No  changes  in  organizational  structure  are 
anticipated  at  wing/base,  MA3COM,  or  HQ  USAF,  however,  addition  of  some  Automated 
Data  Processing  (ADP)  personnel  is  anticipated.  Refer  to  the  AFIRMS  Economic  Analysis 
for  estimates  of  ADP  personnel  requirements.  AFIRMS  terminals  will  be  operated  by 
operations  people.  Essentially,  the  people  who  use  AFIRMS  will  be  performing  the  same 
functions  they  historically  performed  without  the  assistance  of  AFIRMS.  With  AFIRMS, 
they  can  do  their  job  faster,  better,  and  more  comprehensively,  using  more  current  data. 


2A.2.2  User  Operational  Impacts.  There  are  many  operational  impacts,  most  of  which 
involve  a  transition  from  manual  to  automated  procedures  or  a  more  integrated 
perception  of  readiness  problems.  Given  that,  there  are  a  few  specific  impacts  that  can 
be  anticipated  at  this  time. 


Perhaps  the  biggest  impact  is  the  way  that  readiness  information  is  used.  Some 
examples  are  listed  below. 


At  Present  (UNIT REP  C  Ratings) 


Using  AFIRMS 


Measures  each  combat  support  unit 
individually. 


Assesses  unit  and  force 
readiness  to  accomplish 
a  specific  tasking  and  expresses  it 
in  an  output  such  as  sorties. 


Integrates  effects  of  all  combat 
support  units  in  assessing  the 
readiness  of  the  combat  unit  in 
sorties. 


Cannot  tie  readiness  reporting 
to  budget. 


Uses  the  arbitrary  readiness  measures 
of  fully,  substantially,  marginally, 
and  non-combat  ready. 


Ties  readiness  measurement  to  the 
squadron  DOC. 


Reports  readiness  as 
changes  occur  or  monthly. 


Reports  as-is  readiness 
measures  up  the  chain  of 
command.  No  projection  ability. 


Provides  dollars  to  readiness 
information. 


AFIRMS 


Provides  the  wing  commander 
with  a  current,  usable 
quantitative  measure 
of  the  wing's  readiness  to 
perform  a  given  tasking. 


Assesses  capability  to  perform 
taskings  which  need  not  be 
related  to  the  DOC  (e.g., 

ATOs  or  taskings  created  for 
what-if  queries).  Routine 
assessments  will  be  based  on 
fixed  taskings  such  as  W  MP-5. 


Provides  readiness  measures 
which  can  be  recomputed 
daily  and  are  aggregated  for  use 
at  HQ  USAF  within  hours,  subject 
only  to  delays  in  obtaining 
commander  assessments. 


Allows  what-if  queries, 
projections  into  the  future, 
and  comparisons  to  the  past. 
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A  major  impact  is  the  change  in  the  way  data  is  recorded  in  the  wing’s  flying 
squadrons  and  maintenance  organizations.  Most  of  the  data  needed  for  AF1RMS 
is  already  captured  but  a  substantial  amount  is  not  captured  on  automated 
equipment.  For  example,  in  USAFE  the  integrated  computation  of  a  wing's 
capability  for  an  ATO  (called  a  flying  schedule)  is  recorded  on  grease  boards  and 
paper.  The  status  of  an  aircraft  and  aircrew  changes  throughout  the  day  and 
they  are  also  recorded  on  grease  boards  in  the  flying  squadrons,  the  Wing 
Operations  Center  (WOC)  and  the  maintenance  Job  Control  Center.  When  that 
information  is  recorded  on  Cathode  Ray  Tube  (CRT)  terminals  instead  of  grease 
boards,  many  data  collection  problems  can  be  solved. 


Given  the  above  impact,  the  units  need  manual  backup  methods  in  case  of  system 
failures  in  peace,  exercise  or  crisis.  Since  AFIRMS  utilizes  standard  formats, 
these  backup  problems  should  be  minimal.  Avoidance  of  this  possibility  is 
desirable.  Methods  to  limit  degradation  of  performance  and  ways  of  providing  a 
minimal  subset  of  AFIRMS  functions  via  other  systems  must  also  be  specified. 


Other  user  activity  needed  for  operational  AFIRMS  is  the  requirement  for 
additional  duties  for  unit  security  officers/Non-Commissioned  Officers  (NCOs) 
to  encode  the  communications  encryption  equipment  needed  wherever  there  are 
terminals  with  access  to  classified  databases.  In  addition,  those  unit  locations 
requiring  such  terminals  and  not  meeting  Air  Force  security  requirements,  will 
need  to  upgrade  their  facilities. 


There  is  a  need  to  maintain  parametric  data  at  each  site.  This  is  necessary  to 
reflect  judgement  and  because  each  wing  and  MAJCOM  is  different  (aircraft 
mission,  design,  series  (MDS)  and  mission). 


2.4.2.3  User  Development  Impacts.  All  the  impacts  of  developing  an  AFIRMS  are  not 
known  at  this  time,  however,  the  following  impact  can  be  anticipated.  User  effort 
required  in  the  operational  AFIRMS  requires  training  to  use  the  system.  Approximately 
one  week  of  training,  including  hands-on  time,  is  expected  for  the  initial  system 
installation.  As  users  change  due  to  Permanent  Change  of  Station  (PCS)  moves  and/or 
duty  changes,  a  computer-aided  instruction  (CAI)  program  provides  a  new  user  with  the 
initial  ability  to  use  the  system.  New  software  releases,  clear  written  documentation,  and 
hardware  changes  accompany  each  update  to  the  CAI  program.  A  feature  of  the  AFIRMS 
CAI  program  provides  training  that  deals  specifically  with  changes  made  to  the  system 
since  the  previous  release.  This  makes  it  possible  for  an  operator  to  avoid  the  duplication 
of  reviewing  material  with  which  he  is  already  familiar.  Training  courses,  including  CAI, 
are  developed  either  by  the  Air  Force  (Air  Training  Command  (ATC)),  by  the  AFIRMS 
contractor,  or  by  a  support  contractor. 
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2.4.3  AF1RMS  Functions.  The  AFIRMS  system  consists  of  functions  at  three  levels: 
Applications  (User)  Functions;  Basic  AFIRMS  Functions;  and,  Support  Functions.  This 
section  lists  the  functions  at  all  three  levels,  but  focuses  on  the  Basic  AFIRMS  Functions 
in  order  to  illustrate  the  flow  of  AFIRMS  data  in  a  functional  sense.  All  of  these 
functions  must  be  performed.  AFIRMS  system  attribute  requirements  are  for:  data 
fidelity,  reliability,  survivability,  expandability,  affordability,  user  friendliness,  and 
uniqueness  of  source  for  each  type  of  data. 


a.  Applications  (User)  Functions.  The  user's  needs  are  directly  based  on 
measurement  of  readiness  or  sustainability.  Enumerations  at  this  level  vary  by: 

(1)  Whether  readiness  or  sustainability  is  considered 

(2)  Whether  the  evaluations  relate  to  the  past,  present,  or  future 

(3)  Whether  real  or  what-if  conditions  apply 

(4)  The  type  of  question  in  the  case  of  what-if  queries. 

These  functions  relate  directly  to  the  "action"  level  of  Section  2.2. 

b.  Basic  AFIRMS  Functions.  The  building  block  functions  which  are  specific  to 
AFIRMS  and  which  are  used  (in  different  forms)  to  construct  and  to  provide  a 
common  framework  for  understanding  and  accomplishing  the  Applications 
(User)  Functions.  These  functions  are  the  focus  of  this  discussion. 

These  functions  relate  directly  to  the  "method"  level  of  Section  2.2.  There  are 
several  secondary,  or  auxiliary,  services  which  are  not  essential  to  the  basic 
mission  of  AFIRMS  but  are  supplied  to  the  user  in  order  to  facilitate  these 
primary  functions.  These  functions,  while  secondary,  are  essential  to  the 
success  of  AFIRMS  since  they  promote  timely  and  accurate  data.  They  also 
provide  an  avenue  by  which  users  at  all  levels  can  remain  continuously  familiar 
with,  and  accustomed  to  using,  AFIRMS.  Discussion  of  this  is  deferred. 

c.  Support  Functions.  The  standard  building  block  functions  such  as  graphics  or 
data  management  which  might  occur  in  any  system  and  which,  together  with 
specially  written  subfunctions,  are  used  to  provide  the  Basic  AFIRMS  Functions. 


2.4.3. 1  Listing  of  Basic  AFIRMS  Functions.  The  Basic  AFIRMS  Functions  are: 


2.4.3.2  Flow  of  Information  Among  AFIRMS  Functions.  The  underlying  flow  of 
information  among  AFIRMS  functions  is  best  understood  in  terms  of  the  four  Basic 
AFIRMS  Functions.  The  primary  flow  among  those  four  functions,  as  shown  in  Figure  2-7, 
is  consistent  regardless  of  the  Applications  (User)  Functions  being  supported.  Note  that 
this  flow  cuts  across  the  interechelon  flow  depicted  in  Figure  2-6.  That  is,  a  wing  site  and 
a  MA3COM  site  may  cooperate  in  executing  any  one  of  the  four  Basic  AFIRMS  Functions. 
For  example,  to  fully  "Define  Resources,"  the  system  must  examine  the  balances  available 
at  the  HQ  USAF,  MA3COM,  wing,  and  squadron  levels. 

The  central  Basic  AFIRMS  function  is  "Determine  Ability  to  Perform."  Basically,  the 
measurement  of  ability  to  perform  is  carried  out  by  establishing  a  draft  plan  for  meeting 
the  tasking.  The  plan  recognizes  the  limits  imposed  by  shortfalls  in  the  resources 
available  and,  thereby,  both  establishes  the  extent  to  which  the  tasking  can  be  performed, 
and  identifies  the  resources  which  limit  performance. 

The  function  "Determine  Ability  to  Perform"  is  initiated  by  requests  generated  by 
users  or  regularly  scheduled  capability  assessment  needs.  Its  data  is  provided  by  two  of 
the  other  functions:  "Translate  Tasking"  —  a  storer  and  formatter  of  taskings  --  which 
provides  the  tasking  for  the  measurement;  and  "Define  Resources"  —  an  inventory  system 
with  look-ahead  and  look -back  capabilities  —  which  establishes  the  resources  available  to 
carry  out  the  tasking.  The  resources  and  the  tasking  considered  may  be  real  or  what-if 
and  past,  present,  or  future. 

A  final  function,  "Aggregate,  Analyze,  and  Present  Data,"  aggregates  the  data, 
examines  trends,  and  groups  the  data  for  presentation. 

The  two  preparatory  functions,  therefore,  may  occur  in  diverse  forms.  For  all 
Application  (User)  Functions,  however,  the  same  pattern  occurs.  This  consists  of 
establishing  a  tasking  and  a  set  of  resource  availabilities,  and  determining  the  ability  to 
meet  the  tasking  given  the  resources. 
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Figure  2-7.  Basic  AFIRMS  Functions  Information  Flow 


Table  2-1 


$ 

SUMMARY  OP  INPUTS  AND  OUTPUTS  BY  FUNCTION 


FUNCTION 

MAJOR  SOURCES  OF  INPUTS 

MAJOR  USERS  OF  OUTPUT 

"Translate 

Tasking" 

Users  at  all  levels  inputting 
real  or  "what-if"  tasks  either 
standard  (e.g.,  WMP)  or  ad  hoc. 

"Determine  Ability  to  Perform" 
plus  secondary  function  outputs 
to  inform  users  of  status. 

"Define 

Resources" 

Personnel  or  automated  systems 
responsible  for  inventory  status 
and  for  resupply  plans  at  all 
levels. 

"Determine  Ability  to  Perform" 
plus  secondary  function  outputs 
to  inform  users  of  status. 

"Determine 
Ability  to 
Perform" 

"Translate  Tasking"  and  "Define 
Resources" 

"Aggregate,  Analyze,  and 

Present  Data"  plus  secondary 
function  outputs  to  inform 
users  of  status. 

"Aggregate, 
Analyze,  and 
Present  Data" 

The  other  three  modules. 

Users  at  all  levels  who  are 
interested  in  AFIRMS  as  a 
source  of  capability  assessments 
and  of  analyses  based  thereon  — 
see  Section  2.2  (a).  [ 

2.5  Assumptions  and  Constraints.  The  design  of  the  AFIRMS  system  will  be 
based  on  the  assumptions  and  constraints  listed  here. 


a.  Assumptions.  AFIRMS  requirements  and  characteristics  are  satisfied 
by  sharing  hardware,  support  software,  and  communications  with  other 
ADP  systems,  wherever  existing  and  planned  facilities  appropriately 
meet  AFIRMS  requirements. 

( 1 )  Communications. 


(a)  All  intersite  traffic  is  carried  by  communications  links 
provided  by  the  Air  Force. 

(b)  Secure  communications  are  provided  by  those  links. 

(c)  Communications  links  may  be  land  line,  microwave,  or 
satellite. 
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(2)  ADP  Physical  Environment.  Worst  case  environmental  conditions  provide 
the  limiting  conditions  for  ADP  physical  environment  operating  conditions. 

(a)  Area  and  ambient  conditions  at  the  Spangdahiem  WOC  are  typical  of 
worst  case  situations  for  AFIRMS  sites  worldwide,  except  those  of 
deployed  squadrons.  These  worst  case  conditions  for  AFIRMS,  as 
represented  by  USAFE  Main  Operating  Bases  (MOBs)  and  Forward 
Operating  Locations  (FOLs)  are: 

Space: 

a  Ceiling  height  will  be  at  least  8  feet. 

b  There  will  be  no  raised  flooring. 

c  The  access  route  to  the  equipment  locations  will  usually 
be  normal  doorways. 

d  Lateral  space  will  be  limited  in  the  operations  centers  of 
the  various  functional  areas,  i.e.,  WOC,  Maintenance 
Operations  Center  (MOC)/Job  Control,  Munitions 
Control. 

2  Power: 


a  Power  may  be  220  or  240  volts,  50  or  GO  Hz. 

b  There  will  be  frequent  power  interruptions  on  the  base, 
requiring  dependable,  if  not  dedicated,  power  for 
AFIRMS. 

3  Air  Conditioning: 

a  The  overall  facility  ambient  temperature  is  maintained 
between  60  and  90  degrees  F.  However,  the  circulation 
of  the  air  will  often  be  restricted  and  the  local 
temperature  (immediate  to  the  equipment)  in  an 
individual  room  may  reach  100  degrees  F. 

b  Relative  humidity  will  be  between  20  and  80  percent. 

c  No  special  dust,  static  electricity  control,  or  chilled 

water  facilities  are  available. 

(b)  The  worst  conditions  to  be  encountered  for  AFIRMS  at  satellite 
operating  bases  and  other  deployment  locations  are  not  known  in 
detail,  but  will  be  determined  during  the  Analysis  Phase  of  AFIRMS 
initial  implementations.  There  are,  however,  some  assumptions: 

J_  Space: 


31951 


2-25 


2  Power  (usually  provided  by  generator): 

a  Power  is  220  or  240  volts,  50  or  60  Hz. 
b  There  are  frequent  power  interruptions, 
c  There  is  usually  no  backup  power. 

3  Air  Conditioning: 

a  Air  conditioning  is  not  normally  available  at  many 
satellite  locations. 

b  Any  air  conditioning  provided  will  be  uncontrolled  and 
equivalent  to  the  air  conditioning  restrictions  previously 
described. 

c  No  special  dust,  static  electricity  control,  or  chilled 
water  facilities  are  available. 

(3)  Existing  Systems.  Use  of  existing  systems  to  host  AFIRMS  is  desired. 

Such  use  will  substantially  reduce  the  overall  cost  of  AFIRMS,  help  to 
minimize  data  system  redundancies,  and  increase  the  utilization  of  the 
existing  systems.  However,  no  assumptions  are  made  concerning  whether 
or  not  existing  systems  can  be  used  by  AFIRMS.  The  feasibility  of  such 
use  must  be  determined  on  a  case  by  case  basis,  depending  on  the 
availability,  capability,  and  capacity  of  target  systems.  The  Segment 
Implementation  Plans  for  each  MAJCOM  must  identify  target  systems 
which  are  to  be  the  subject  of  detailed  analysis  during  the  Analysis  Phase 
of  the  initial  block  implementations.  Specifically,  this  analysis  covers  the 
hardware,  software,  and  database  management  availability  at  each  site 
installation  within  the  MA3COM.  Such  availability  is  then  evaluated 
against  AFIRMS  requirements. 

Constraints. 

(1)  AFIRMS  is  subject  to  the  Privacy  Act  and  security  requirements.  The 
levels  are  documented  in  the  Data  Requirements  Document  (DRD). 

(2)  While  AFIRMS  can  simplify  and  expedite  the  tracking  of  data,  it  cannot 
eliminate  real  world  limit"  on  the  various  methods  in  use  today: 

(a)  Records  of  on-hand  amounts  maintained  from  reports  of  uses  and 
receipts  are  inaccurate  once  the  inevitable  human  error 
(transposition,  misplaced  decimal,  etc.)  has  occurred. 

(b)  Measurements  of  actual  levels  (as  with  fuels)  cannot  be  more 
current  than  the  most  recent  reading. 

(c)  Complete  recounts  of  stocks  can  be  accurate,  but  (because  of  cost) 
tend  to  be  infrequent. 

These  are  not  problems  introduced  by  AFIRMS;  they  are  problems  with 
which  AFIRMS  must  deal. 


(3)  The  status  of  various  hardware  and  software  systems  which  may  impact 
AFIRMS,  as  interfaces  or  hosts,  changes  within  the  phased  approach  to 
AFIRMS  implementation.  This  means  that  development  plans  must 
include  alternate  interface  components  for  AFIRMS.  The  elements  must 
be  designed  so  that  one  will  be  appropriate  for  an  initial  environment 
while  another  can  be  substituted  to  deal  with  a  revised  environment.  The 
alternate  elements  must  connect  to  a  solid  basic  framework  built  on  clear 
definitions  of  how  capability  is  to  be  assessed,  and  how  the  command 
levels  cooperate  with  each  other  to  make  full  use  of  the  assessments.  The 
AFIRMS  Management  Plan,  Volume  3  (System  Interface  Program), 
coordinates  the  evolving  interface  requirements. 

(4)  The  environment  and  the  requirements  for  AFIRMS  will  differ  from 
MAJCOM  to  MAJCOM,  and  (to  a  lesser  extent)  from  wing  to  wing.  Again, 
a  solid  basic  framework  with  flexible  options  is  mandatory.  The  AFIRMS 
Management  Plan,  Volume  2  (Configuration  Management  Program), 
coordinates  these  differing  requirements. 


SECTION  3.  DETAILED  CHARACTERISTICS 


i 


This  section  discusses  the  detailed  characteristics  of  AFIRMS.  Sections  are  included  that 
address  performance,  functional  breakdown,  inputs  and  outputs,  database  characteristics, 
failure  contingencies,  and  security. 


3.1  Specific  Performance  Requirements.  AFIRMS  performance  requirements  can  be 
examined  from  three  perspectives: 

a.  AFIRMS  ability  to  adapt  (flexibility).  AFIRMS  must  provide  a  skeleton  structure 

that  matches  the  specific  requirements  of  HQ  USAF,  each  MAJCOM,  ana  each 

wing  to  an  AFIRMS  site  with  compatible  hardware/software  capability. 

Additionally,  it  has  the  capability  to  grow;  i.e.,  add/change  system  focus  as  time 

passes. 

(1)  An  AFIRMS  site  is  a  complement  of  hardware  (computers,  black/white  and 
color  CRTs/cameras/hardcopy  devices,  communications/crypto,  and  data 
storage  devices)  and  software  (operating  system,  Database  Management 
System  (DBMS)  data  entry,  models,  menu  selection,  etc.). 

(2)  Sites  (different  echelons  and  different  locations,  same  echelons)  are 
constructed  from  modular  hardware  and  software  components.  The  modular 
software  is  written  in  a  host  independent  high  order  language  for 
transportability  among  different  hardware  configurations. 

(3)  This  hard  ware/soft  ware  building  block  approach,  coupled  with  transportable 
software,  assures  that  operational  AFIRMS  expansion  in  the  future  can  follow 
a  systematic  pattern  with  an  optimum  amount  of  standardization  among  sites. 

(4)  Ease  of  developing  new  functions,  i.e.,  if  it  is  desired  that  information 
contained  within  the  database  be  viewed  in  a  "new  way,"  it  must  be 
straightforward  to  provide  the  new  data  view. 

(5)  Ability  for  users  with  the  appropriate  password  privileges  to  directly 
inter rogate/update  the  AFIRMS  database  in  accordance  with  prescribed 
access  and  security  authorizations. 

(6)  Availability  of  standard  utilities  that  allow  the  user  to  chart  data  entered 
from  a  keyboard  or  extracted  from  the  AFIRMS  database  rapidly.  This 
concept  allows  the  user  to  process  selected  data  through  models  that  are  part 
of  an  AFIRMS  runtime  library. 

(7)  Ability  to  interface  an  AFIRMS  site  to  other  Air  Force  systems  after  the 
AFIRMS  site  has  been  designed  and  installed.  The  central  idea  is  that  the 
AFIRMS  information  flows  are  sufficiently  defined  so  as  to  ensure  that  new 
interfaces  blend  naturally  into  the  existing  system. 
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AFIRMS  ability  to  meet  the  functional  needs  of  the  Air  Force.  AFIRMS  ensures 
that  the  many  users  at  each  echelon  are  able  to  obtain  the  information  that 
they  require  within  the  time  frame  in  which  they  require  it. 


AFIRMS,  because  it  consists  of  a  collection  of  sites,  provides  a  spectrum  of 
functional  performance  quality  that  may  be  available  at  a  given  installation, 
depending  upon  current  communication  network  status  and  the  operational 
status  of  the  interfaced  systems. 

The  AFIRMS  LPP  established  the  value  of  the  following  services  in  relation  to 
the  readiness  assessment  function  and  value  of  payback  to  users. 

(1)  Manually  enter/retrieve  data  into/from  a  database,  using  one  or  more  of 
the  device  types  listed  below,  in  order  of  preference. 

(a)  CRT  Keyboard 

(b)  Special  Function  Keyboard 

(c)  CRT  Joystick  Cursor 

(d)  Digitizer  Pad  (no  proven  requirement) 

(e)  Track  ball  or  mouse  type  cursor  control  (no  proven  requirement) 

(2)  Automatically  or  semi-automatical  ly  enter /read  data  into/from  a 
database  using  a  magnetic  medium  such  as  tape,  disk,  or  diskette. 

(3)  Generate  selected  CRT  color  and  black/white  displays  that  provide 
graphic  capability-related  data,  human  engineered  for  maximum 
information  transfer  to  the  user.  User  interaction  with  the  AFIRMS 
system  for  these  displays  is  through  a  guided  menu  and  command  language 
system.  Display  options  range  widely  in  scope,  from  simple  displays  of 
aircrew  personnel  charts,  to  sortie  generation  from  ATOs,  to 
historical/projected  resource  use  (fuel,  munitions,  spare  parts,  etc.),  over 
time.  Displays  are  matched  to  sites  in  consonance  with  the  site's  specific 
requirements. 

(4)  Permit  the  user  to  ask  what-if  questions,  i.e.,  how  do  changes  in  the 
values  of  user-selected  database  entities  impact  a  particular  product. 

This  allows  a  user  to  perform  his  own  sensitivity  and  trade-off  analyses. 
User  input  interaction  with  the  system  is  through  a  data  entry  device 
identified  in  ( I);  output  is  through  displays,  as  defined  in  (3). 

(5)  Query  his  own  database  in  accordance  with  access  control  and  security 
mechanisms. 

AFIRMS  perception  by  the  user  (the  individual  working  at  an  AFIRMS 
terminal).  AFIRMS  must  be  a  "friendly"  tool  that  is  engineered  to  minimize 
user  fear,  fatigue,  frustration,  and  the  likelihood  of  user  error. 


AFIRMS  is  an  information  processing  system  that  is  user  intensive,  that  is,  in 
general,  users  enter  data  through  a  data  capture  device  and  users  request 
capability  status  onto  an  output  display.  Thus,  it  is  clear  that  much  attention  is 
given  to  providing  effective  and  meaningful  interactions  between  users  and 
AFIRMS.  The  requirements  are  stated  as  follows: 

(a)  AFIRMS  interactive  CRT  terminal  response  time  to  user  requests  is 
minimized.  Response  times  will  vary  depending  on  the  complexity  of  the 
queries  and  the  types  of  processes  involved  with  the  query.  For  planning 
purposes,  the  following  response  times  are  used  for  a  query  limited  to  the 
local  site: 

J[  Complex  Query  -  1 1  seconds  or  greater. 

2  Medium  Query  -  4  seconds  to  10  seconds. 

3  Simple  Query  -  1  seconds  to  3  seconds. 

The  terms  complex,  medium,  and  simple  do  not  have  precise  definitions  at 
this  time.  Specific  definitions  are  determined  in  the  Analysis  Phase  of 
each  segment  implementation  block  in  accordance  with  the 
MAJCOM-specific  requirements  and  their  interactions  with  HQ  USAF. 

(b)  The  bulk  of  AFIRMS  data  entry  is  made  through  standardized  forms  that 
are  presented  on  a  CRT  display.  The  user  enters  (types)  data  into 
selected,  predefined  fields  within  these  forms  just  as  if  he  were  doing  the 
job  with  paper  and  pencil.  Each  field  is  predefined  in  terms  of  its  length, 
type  of  characters  admissible,  etc.  The  intent  is  to  simplify  data  entry 
and  make  it  less  error  prone. 

(c)  CRT  data  entry  forms  and  AFIRMS  products  are  human  engineered  to 
minimize  eye  fatigue  while  rapidly  conveying  the  intent  of  the  screen. 
Color  choices,  placement  and  size  of  figures,  plot  type(s),  etc.,  play  a  role 
in  AFIRMS  product  design  that  is  as  important  as  the  information  content 
itself. 

(d)  AFIRMS  offers  many  choices  to  the  user.  Once  these  choices  are 
mastered,  it  is  necessary  that  the  user  can  "get  on  to  his  job"  rapidly. 
Therefore,  AFIRMS  has  menus  that  lead  a  novice  to  the  task  he  wishes  to 
perform  and  a  command  language  that  allows  the  seasoned  user  to  enter  a 
single  command  which  gives  him  immediate  access  to  the  task  that  he 
wishes  to  perform. 

(e)  Since  AFIRMS  databases  store  data  at  several  classification  levels, 
AFIRMS  works  through  authorization  codes  to  permit  user  access  to  the 
database(s)  and  displays.  Menus  and  commands  identified  in  (d)  are 
tailored  to  authorization  codes,  thereby  limiting  the  apparent  extent  of 
the  system  capabilities  to  users  with  limited  privileges.  It  should  be  noted 
that  TEMPEST,  COMSEC,  physical  security,  procedural  controls,  and 
software  access  techniques,  are  part  of  the  AFIRMS  Security  Plan. 


3.1.1  Accuracy  and  Validity.  There  are  two  categories  of  accuracy  and  validity  that  must 
be  addressed.  The  first  is  related  to  electronic  manipulation/storage/transmission  of  data 
in  the  AF1RMS  system.  The  second  is  related  to  the  interface  between  the  user  and  the 
AFIRMS  system. 


a.  Electronic  Manipulation/Storage/Transmission. 

( 1)  The  nature  of  the  models/displays  created  with  AFIRMS  are  based 
primarily  on  integers  (numbers  of  people,  aircraft,  sorties,  etc.)  and  on 
near  integers  —  one  or  two  decimals  at  most  for  supplies  which  are  not 
simply  counted  (e.g.,  liquids).  No  displayed  result  need  have  precision  of 
more  than  6  digits.  The  required  precision  of  intermediate  variables  is 
based  on  the  end  products  to  which  they  lead.  When  significant  digits 
exceed  6  figures,  a  scaling  factor  with  rounding  is  applied  to  limit  the 
significant  digits. 

(2)  Parity  checks  and/or  cyclic  redundancy  codes  ensure  that  the  data 
actually  used  internal  to  the  AFIRMS  sites  has  an  error  probability  well 
below  minimum  requirements  as  set  forth  in  the  System  Specification. 

b.  User  Interfaces  to  AFIRMS.  The  user  interfaces  of  interest  here  are  those 
interfaces  that  introduce  new  information  into  AFIRMS.  The  concern  is  that 
this  information,  which  is  destined  to  enter  a  database,  be  valid.  Valid  here 
means  that: 

( 1)  The  individual  entering  the  information  is  authorized  to  do  so  (i.e.,  only 
fuels  shop  personnel  may  be  authorized  to  update  fuels  information,  using 
fuels  data  forms). 

(2)  The  information  is  as  "error  free  as  is  possible."  This  suggests  that  input 
data  must,  in  general,  be  entered  through  well  engineered  forms  that 

I  prompt  the  user  and  check  field  contents.  The  forms  must  provide  for 

easy  identification  and  correction  of  errors  and  omissions. 

I 


3.1.2  Timing.  The  discussion  of  the  AFIRMS  user  environment  in  the  preceding  material 
dealt  with  system  response  time  as  perceived  by  the  user.  This  user  response  time, 
however,  is  only  a  limited  topic  in  the  general  area  of  timing,  which  deals  also  with  the 
following  items: 


Frequency  of  database  updates,  which  are  addressed  in  the  System  and 
Subsystem  specifications. 


Frequency  of  model  runs,  the  question  of  whether  the  model  should  be  run  every 
time  a  piece  of  data  that  serves  as  input  to  the  model  is  changed,  whether  the 
model  should  be  run  at  f  ixed  intervals,  or  whether  the  model  should  be  run  each 
time  displays  created  from  data  within  the  databases  and/or  queries  to  the 
database  require  results  provided  by  the  model. 
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c. 


Data  redundancy  in  distributed  databases.  This  may  be  required  to  speed 
response  time  to  queries  and  to  ensure  that  the  loss  of  an  AFIRMS  functional 
area  with  data  critical  to  another  AFIRMS  functional  area  is  backed  up  so  that 
the  surviving  functional  area  can  operate  autonomously,  or  at  least  provide 
some  functionality  for  degraded  operations. 


3.2  Functional  Area  System  Functions.  The  AFIRMS  system  consists  of  functions  at 
three  levels:  Applications  (User)  Functions;  Basic  AFIRMS  Functions  (including  Secondary 
Functions);  and,  Support  Functions.  This  section  graphically  illustrates  the  way  in  which 
functions  at  one  level  are  dependent  on,  and  use,  the  functions  at  other  levels.  Each 
function  is  then  discussed  briefly  as  an  independent  element.  Finally,  several  overall 
requirements  which  apply  to  any  AFIRMS  function  are  addressed. 

Figure  3-1  illustrates  the  three  levels  and  portrays  the  relationships  among  these 
functions.  The  upward  arrows  indicate  that  the  lower  level  functions  support  those  above 
them.  Only  some  of  the  supports  are  shown.  In  fact,  any  lower  level  function  may 
support  any  function  in  the  level  above.  Some  intralevel  support  exists,  although  to 
examine  it  would  add  needless  complexity  to  this  discussion. 


3.2.1  Applications  (User)  Functions.  These  are  the  functions  of  AFIRMS  in  terms  which 
might  be  used  by  the  user,  that  is,  terms  which  might  appear  in  a  menu  system  defining 
the  results  to  be  provided.  A  limited  subset  of  these  functions  is  planned  for  in  the  initial 
operational  AFIRMS  in  each  MAJCOM.  (See  the  Evolutionary  Implementation  Plan).  The 
Applications  (User)  Functions  are  defined  as  follows: 


a.  Measure  (and  aggregate)  readiness  vs.  standard  tasking.  This  function  is 
generally  comparable  to  the  regular  measurement  of  readiness  performed  today 
by  the  UNITREP  system.  The  measurement,  however,  rather  than  being  based 
on  counts  of  some  of  the  resources  held  by  the  unit,  will  be  based  on  the  ability 
of  the  unit  to  execute  the  standard  tasking. 

b.  Measure  (and  aggregate)  sustainability  vs.  standard  tasking.  This  function  is  an 
extension  of  the  measurement  of  readiness.  That  is,  once  the  ability  to  perform 
one  day's  tasking  is  completed,  the  resources  available  for  the  second  day  are 
computed  and  the  ability  of  the  unit  to  perform  the  second  day's  tasking  is 
computed.  This  cycle  is  repeated  until  the  capability  of  the  unit  for  the 
complete  sustainability  period  has  been  measured. 


c.  Measure  (and  aggregate)  readiness  vs.  one-time  tasking.  This  function  is  also  an 
extension  of  the  measurement  of  readiness.  However,  the  tasking  against  which 
performance  is  to  be  measured  will  not  be  a  standard  tasking  stored  in  the 
system,  but  a  real  or  speculative  tasking  which  is  usually  either  real-time  or 
related  to  a  current  situation.  The  tasking  involved  may  be  one  which  is  not 
fully  detailed. 

d.  Measure  (and  aggregate)  sustainability  vs.  one-time  tasking.  This  function  is 
identical  to  the  function  on  measuring  readiness  against  one-time  tasking  which 
was  just  discussed,  except  for  a  difference  in  the  time  period  involved. 

e.  Measure  (and  aggregate)  readiness  or  sustainability  vs  revised  standards,  and/or 
revised  standard  tasking  using  historic  data.  This  function  addresses  the  need 
to  compare  present  capability  to  past  capabilities  even  though  the  standards  of 
measurement  used  today  differ  from  those  used  in  the  past.  This  function 
cannot  be  performed  under  current  practices  since,  today,  the  raw  data  is 
converted  to  C-ratings  which  do  not  provide  a  basis  for  recomputing  readiness 
under  revised  standards.  To  meet  this  need,  A  FIR  MS  provides  for  a  procedure 
to  capture  snapshots  of  unit  data  on  a  preprogrammed,  periodic  basis.  The 
data,  which  is  normally  held  off-line,  is  available  for  recomputation  from  the 
ground  up  of  readiness  or  sustainability  against  revised  taskings  or  standards. 

Factors  added  to  the  evaluation  procedure  at  any  time  in  the  future  which  were 
not  considered  prior  to  that  time,  are  either  assumed  to  be  equal  to  some 
arbitrary  value  or  this  kind  of  comparison  is  not  practical. 

f.  Assist  in  allocation  of  resources  (physical  or  fiscal)  —  forecast  results  of  trial 

or  final  allocations.  In  the  simplest  case.  AFIRmS  is  able  to  accept  an  input  | 

showing  a  proposed  allocation  of  one  or  more  resources  and  provide  evaluations 
of  the  resultant  changes  in  readiness  or  sustainability. 

g.  Assist  in  task  assignment  —  forecast  results  of  trial  or  final  assignments.  This 
function  is  directly  analogous  to  the  function  of  assisting  in  resource 
allocation.  A  user  input  tasking  assignment  is  evaluated  or  an  internal  search  is 
made  for  a  proposed  tasking  assignment  which  is  presented  to  the  user  for  his 
evaluation,  acceptance,  rejection,  change  or  replacement  before  proceeding 
with  the  other  option. 

h.  Assist  in  out-year  budget  plans  (dollars  to  readiness)  —  forecast  results  of  trial 
or  final  allocations  based  on  standard  or  user  supplied  assumptions.  This  is  the 
congressional ly  mandated  question  of  dollars  in,  readiness  out.  It  can  be  related 
to  the  two  preceding  functions  (which  dealt  with  taskings  and  resources)  in  that, 
again,  the  user  postulates  a  condition  and  AFIRMS  is  asked  to  evaluate  the 
result.  Since  the  congress  has  posed  the  question  in  terms  of  a  change  in  an 
out-year  budget,  two  evaluations  must  be  made;  one  with  the  change,  and  one 
before  the  change.  AFIRMS  may  participate  in  setting  some  of  the  many 
assumptions  on  which  such  an  evaluation  must  rest. 


3.2.2  Basic  AFIRMS  Functions.  For  any  of  the  Applications  (or  User)  Functions  to  be 
met,  AFIRMS  performs  four  characteristic  functions.  The  central  function  is  "Determine 
Ability  to  Perform."  Two  of  the  other  functions  prepare  for  "Determine  Ability  to 
Perform."  The  other  function  deals  with  trends,  aggregation  and  reporting. 
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All  four  functions  include  various  subfunctions,  any  of  which  may  be  used  when  the 
Sasic  AF1RMS  Function  is  being  used  as  a  building  block  for  a  specific  Applications  (User; 
Function.  These  four  functions  are  characteristic  of  the  AFIRMS  tasking  based  readiness 
measurement  approach.  Future  evolution  of  AFIRMS  is  likely  to  lead  to  modifications  of 
subfunctions  within  these  major  functions.  For  example,  the  degree  to  which  AFIRMS 
gathers  data  on  current  resources  from  other  systems  could  change  significantly.  At  any 
one  time,  different  AFIRMS  at  the  same  echelon  may  be  operating  in  different  ways  in 
this  regard.  The  basic  role  of  the  four  functions,  however,  is  likely  to  remain  constant. 


a.  Translate  Tasking  can  be  a  relatively  simple  function  or  it  can  be  quite 
complex.  The  tasking  may  be  current  and  known  or  part  of  a  what-it  exercise. 

In  either  case,  anything  which  contributes  to  knowing  the  tasking  to  be  used  in 
the  evaluation  is  part  of  "Translate  Tasking." 

Simplicity  arises  when  the  tasking  to  be  used  is  a  standard  which  is  stored  in  the 
system  in  the  correct  format.  This  assumes  considerable  work  done  in  advance 
to  develop  the  standard  from  a  starting  point  such  as,  the  WMP  which  does  not 
provide  details  required  by  AFIRMS  when  it  performs  "Determine  Ability  to 
Perform." 

Complexity  arises  if  a  new  tasking  lacks  the  details  required  for  the  standard 
format.  This  occurs  when  the  tasking  is  not  a  standard  tasking  stored  in  the 
system,  but  a  real  or  speculative  tasking  which  is  usually  either  real-time  or 
related  to  a  current  situation.  Such  taskings  are  not  always  fully  detailed.  In 
such  cases  "Translate  Tasking"  provides  the  prompts  to  help  the  users  (possibly 
at  more  than  one  level)  to  add  the  needed  detail.  Possibly,  some  of  the  prompts 
will  be  based  on  resource  availability  or  other  factors. 

The  reference  to  details  here  and  in  earlier  discussions  should  not  be 
misinterpreted.  The  details  may  include  major  decisions.  This  detailing  deals 
with  dividing  the  tasking  over  units  and  with  selections  of  weapon  systems  and 
munitions. 

AFIRMS  has  a  defined  set  of  displays  that  allow  users  to  enter  and  translate 
tasking  requests  efficiently  and  also  allows  users  to  view  resulting  schedules. 

b.  Define  Resources,  like  "Translate  Tasking,"  can  be  a  relatively  simple  function 
or  it  can  be  quite  complex.  The  resources  may  be  current  and  known,  or  part  of 
a  what-if  exercise.  Whichever  is  true,  anything  which  contributes  to  knowing 
the  resources  to  be  used  in  the  evaluation  is  part  of  "Define  Resources." 

Simplicity  arises  when  the  resources  to  be  used  are  those  currently  on-hand  at 
the  unit.  Complexity  arises  if  the  resources  are  those: 

(1)  Which  existed  sometime  in  the  past. 

(2)  Which  result  from  a  reallocation  of  resources. 

(3)  Which  result  from  a  change  in  the  Air  Force  budget  in  the  out-years. 


m 


AFIRMS  captures  data  through  manual  entry,  computer-to-computer 
direct  communications,  and  storage  media  that  can  be  physically 
transported  between  computers.  It  also  creates  data  elements  through 
internal  computation  (for  example,  a  model  creates  a  readiness 
assessment  based  on  resources  and  tasking).  AFIRMS  also 
distinguishes  between  real  inventoried  items  (actuals)  and  planned 
allocated  items,  and  can  provide  an  assessment  of  unit  readiness  if 
the  wing  had  it's  authorized  resources. 

One  aspect  of  defining  resources  is  important  in  the  dollars  to 
readiness  arena.  When  complex  decisions  must  be  made,  it  is  valuable 
to  have  the  ability  to  examine  alternatives  and  make  trade-offs 
rapidly,  with  the  intent  of  maximizing  readiness  on  a  fixed  budget 
(ceiling  number  of  dollars).  Such  a  trade-off  might  deal  with  the 
relationship  between  the  number  of  weapons  of  various  types  assigned 
to  a  wing  as  a  function  of  the  number  and  types  of  aircraft  at  that 
wing.  The  AFIRMS  system,  at  the  MAJCOM  and  HQ  USAF  sites,  will 
provide  tne  user  with  these  capabilities. 

Determine  Ability  to  Perform  is  the  least  variable  of  the  three  Basic 
AFIRMS  Functions.  It  includes:  the  generation  of  mission  sorties 
and  alert  sorties,  the  adjustment  of  the  result  to  account  for 
discrepancies  between  automatic  and  human  sortie  generation,  and  the 
calculation  of  resources  consumed.  Given  current  and  forecast 
environmental  factors,  AFIRMS  transforms  WMPs,  ATOs,  OPlans,  and 
what-if  exercises  into  measurable  tasking,  computes  current  readiness 
to  perform  the  task,  projects  readiness  into  the  future,  calculates 
resources  consumed  in  performing  the  task,  and  provides  a  time  phased 
model  of  task  accomplishment 

Aggregate,  Analyze  and  Present  Data  deals  with  the  task  of  properly 
grouping  data  from  various  wings  to  provide  meaningful,  useful 
information  at  MAJCOM  and  HQ  USAF  levels.  It  also  develops  trend  and 
variability  data  to  facilitate  exception  type  reporting  on  unusual 
developments  in  day-to-day  data.  Aggregation  refers  to  the  creation 
of  a  composite  understanding  of  the  readiness  and  sustainabili ty  of  a 
number  of  units.  Thus,  a  MAJCOM  with  many  reporting  wings,  each  with 
its  own  deficiencies  and  meritorious  qualities,  must  assess  the 
readiness  (and  sustainability)  of  all  units  taken  as  a  whole. 

Secondary  AFIRMS  Functions.  These  functions  are  necessary,  but  not 
sufficient  to  AFIRMS.  For  example,  if  AFIRMS  were  to  obtain  all  of 
its  resource  data  from  other  systems,  the  secondary  function  relating 
to  resource  status  would  remain  with  those  other  systems.  So  those 
services,  and  the  others  discussed  in  this  section,  may  be  part  of 
AFIRMS  as  such,  only  temporarily.  It  is  for  this  reason  that, 
although  these  services  play  a  vital  role  in  AFIRMS  as  it  is  now 
constituted,  they  are  referred  to  here  as  Secondary  AFIRMS  Functions. 
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The  associated  Secondary  Functions  and  the  Basic  Functions  to  which 
they  relate  are: 


(1)  Display  resource  inventories  and  status  (used  in  "Define 

Resources").  In  order  to  encourage  prompt  and  accurate  input  of 
resource  data,  AFIRMS  provides  graphic  displays  of  unit  resource 
status.  Since  these  displays  provide  daily,  visible  uses  for 
the  data  input  to  AFIRMS,  regular  and  reliable  input  is 
encouraged. 
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(2)  Report  reduction  of  resources  past  thresholds  (used  in  "Define 
Resources").  As  another  method  of  ensuring  careful  maintenance  of 
resource  data,  AFIRMS  provides  warnings  when  user  specified  resources 
fall  below  established  limits.  This,  like  the  resource  displays,  heightens 
interest  on  the  part  of  wing  personnel  in  maintaining  a  high  level  of 
timeliness  and  accuracy  in  the  resource  data  provided. 

(3)  Display  tasking  (used  in  "Translate  Tasking"  and  "Determine  Ability  to 
Perform").  The  concept  of  making  the  AFIRMS  resource  data  visible  is 
comparable  to  the  role  of  tasking  displays  provided  by  AFIRMS.  These 
displays  provide  the  same  advantages  of  immediate  update,  base-wide 
consistency,  and  visual  clarity  found  in  the  resource  screens. 

(4)  Display  information  on  an  evolving  schedule  (used  in  "Determine  Ability 
to  Perform").  AFIRMS  carries  out  some  stages  of  the  sortie  generation 
process  as  part  of  its  method  of  executing  "Determine  Ability  to 
Perform."  The  products  are  provided  to  the  user  for  his  convenience  so 
that  the  process  under  way  becomes  integrated  into  wing  activities.  (The 
procedure  also  helps  to  test  the  AFIRMS  algorithms.) 


3.2.3  Support  Functions.  At  any  stage  in  AFIRMS  processing,  it  may  be  necessary  to  have 
in  use  several  support  functions  such  as,  maintaining  security,  providing  communications, 
providing  displays  to  accepting  input  from  a  user,  and  storing  and  retrieving  data. 


These  are  functions  which  occur  in  many  systems.  They  are  so  basic  that  operating 
systems  and  commercially  available  software  packages  are  available  to  provide  all  or 
parts  of  most  of  them.  The  specific  requirements  which  AFIRMS  imposes  in  each  of  these 
areas  is  discussed  once.  The  Support  Functions  are  referenced  (or  simply  assumed) 
throughout  the  discussion  of  Basic  AFIRMS  Functions.  In  such  references,  there  will  be 
no,  or  minimal,  discussion  of  the  implied  Support  Function  requirements  or  how  they  are 
met.  • 


a.  Produce  graphic  displays.  AFIRMS  is  an  interactive  system.  It  relies 

extensively  on  softcopy/CRT  displays  to  aid  in  the  manual  capture  of  data  and 
to  present  analysis  results  back  to  users.  The  majority  of  AFIRMS  manual  data 
entry  is  provided  through  "fill-in-the-forms"  techniques  in  which  a  user 
interactively  fills  in  fields  of  a  form  displayed  on  a  CRT.  The  majority  of 
AFIRMS  readiness  displays  make  extensive  use  of  color  graphics  to  permit  the 
user  to  quickly  grasp  complex  readiness  issues.  Critical  products  that  signal 
out-of-bounds  conditions  are  highlighted. 


b.  Store  and  retrieve  data.  Normal  database  services  must  be  provided.  Of 

particular  interest  is  the  degree  to  which  AFIRMS  must  be  capable  of  working 
with  both  real  and  supposed  data.  This  capability  is  essential  to  operations  in 
the  exercise  mode.  The  degree  to  which  multiple  suppositions  are  supported  is 
identified  in  the  Database  Specifications. 
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Store  and  retrieve  data.  Normal  database  services  must  be  provided.  Of 
particular  interest  is  the  degree  to  which  AFIRMS  must  be  capable  of  working 
with  both  real  and  supposed  data.  This  capability  is  essential  to  operations  in 
the  exercise  mode.  The  degree  to  which  multiple  suppositions  are  supported  is 
identified  in  the  Database  Specifications. 

Provide  user  interface  to  AFIRMS  services.  This  is  the  function  that  an 
AFIRMS  user  enters  when  he  has  successfully  logged  into  AFIRMS.  It  leads  the 
novice  user  to  the  AFIRMS  service  of  interest  by  a  series  of  easy  steps,  but 
allows  the  experienced  user  rapid  access.  The  access  provided  will  comply  with 
the  security  provisions  oi  Section  3.6.  A  HELP  facility  allows  a  user  to 
familiarize  or  refamiliarize  himself  with  how  the  system  is  used. 

Most  importantly,  this  interface  function  controls  the  structure  of  the  system 
provided  to  the  user.  In  many  uses,  this  means  that  the  software  to  extract  a 
screen  from  a  database  is  activated.  However,  for  some  purposes,  it  implies 
the  activation  and  linking  of  the  correct  subfunctions  from  the  Basic  AFIRMS 
Functions  at  all  three  levels. 


Maintain  security.  This  subject  is  discussed  in  Section  3.6. 

Provide  communications  (Intersite).  It  is  anticipated  that  AFIRMS  will  rely  on 
a  common  user  network  for  cost,  security,  and  survivability  reasons. 
Operational  AFIRMS  is  hierarchical,  suggesting  that  information  need  flow 
vertically  among  sites  at  different  echelons  with  limited  need  for 
communications  among  sites  at  the  same  echelon.  This  logical  hierarchical 
structure  places  no  restriction  or  limitation  on  the  physical  communications 
links  that  may  be  used  to  move  information  between  sites.  For  example,  there 
is  no  reason  why  a  link  from  one  wing  site  to  its  MA3COM,  cannot  pass  through 
a  second  wing  site.  The  determination  as  to  whether  this  does,  in  fact,  occur  is 
a  function  of  available  links  and/or  costs  to  provide  direct  links. 

The  distributed  database  structure  of  AFIRMS  may  impose  additional 
requirements  on  AFIRMS  site-to-site  communications. 

Provide  communications  (local). 

Produce  tabular  displays. 

Edit  input  data  -  check  reasonableness. 

Interface  to  other  systems.  Part  of  the  charter  of  AFIRMS  is  to  avoid  data 
redundancy  where  possible.  This  means  maximizing  the  use  of  USAF  data 
systems  to  provide  AFIRMS  information.  The  following  data  systems  are 
identified  for  potential  interface  to  AFIRMS.  The  summary  of  each  system  is 
provided  in  the  following  pages.  For  a  more  detailed  analysis,  refer  to  the 
individual  system  studies. 


I 


Combat  Fuels  Management  System  (CFMS).  CF MS  is  currently 
operational  as  a  standard  USAF  data  system  and  runs  on  a  secure  H6000 
series  computer  at  the  major  command  level  It  is  the  only  fuels  system 
in  use  today  and  provides  daily  information  on  jet  fuel,  liquid  oxygen  and 
liquid  nitrogen.  CFMS  does  not  allocate  fuel  by  unit,  which  is  required  by 
AFIRMS.  CFMS  is  projecting  transition  from  keypunch  card  data  entry  to 
automated  entry  via  tape  in  FY85.  Similar  input  automation  may  be 
applicable  at  the  unit  level  prior  to  data  aggregation  to  the  MAJCOM. 
CFMS  is  included  as  a  potential  interface  for  operational  AFIRMS. 

Air  Force  Operations  Resource  Management  System  (AFORMS). 

AFORMS  is  operational  on  the  B3500  on  most  bases  and  does  have 
information  relevant  to  AFIRMS  in  the  aircrew  training  and  availability 
areas.  AFORMS  is  transitioning  to  Phase  IV  equipment.  Skills  of  airmen 
can  be  tracked  along  with  flight  data  on  medical  and  training  status. 

Since  aircrews  are  a  key  resource  to  consider  when  assessing  combat 
capability  in  a  unit,  and  this  information  is  available  at  the  unit  level, 
AFORMS  has  been  highlighted  as  a  good  candidate  for  interface  with 
AFIRMS. 

Combat  Supplies  Management  System  (CSMS).  CSMS  is  currently 
operational  on  the  H6000  and  contains  supply  data  for  bases  on  a 
worldwide  basis.  Base  Level  Self-Sufficiency  Spares  (BLSS),  Peacetime 
Operating  Stock  (POS)  and  Other  War  Reserve  Materiel  (OWRM),  are 
tracked  and  updated  on  a  daily  basis.  CSMS  uses  the  Dyna- METRIC 
modeling  technique  at  the  major  command  level  to  provide  capability 
assessment  in  a  combat  environment.  Currently,  only  critical  aircraft 
reparable  spares  are  assessed  for  this  purpose. 

Weapon  System  Assessment  Model  (WSAM).  WSAM,  (formerly  the  Ogden 
Prototyped,  is  a  spares  modeling  system  for  the  F-16  and  runs  on  a 
VAX/VMS  minicomputer.  The  system  has  extensive  data  on  the  F-16  and 
can  also  run  the  Mini-Dyna-METRIC  model  for  combat  capability 
assessment.  This  has  been  a  prototyping  system  used  for  experimental 
purposes  by  HQ  Air  Force  Logistics  Command  (AFLC).  Most  of  the  work 
was  accomplished  in  database  development  techniques.  Current  plans  are 
to  incorporate  these  initiatives  into  the  Weapon  System  Management 
Information  System  (WSMIS).  For  this  reason,  WSAM  was  eliminated  as  an 
interface  with  AFIRMS. 

Weapon  System  Management  Information  System  (WSMIS).  Currently 
under  development,  WSMIS  intends  to  incorporate  information  on  spares 
(from  CSMS)  with  consumables  (fuel  and  munitions)  to  obtain  an  overall 
unit  capability  assessment.  WSMIS  is  going  to  use  the  Dyna-METRIC 
model  for  spares  and  the  Contingency  Operation/Mobility  Planning  and 
Execution  System  (COMPES)  for  mobility  and  resupply  information.  Due 
to  the  broad  scope  of  WSMIS  and  its  location  on  the  WWMCCS 
Intercomputer  Network  (WIN)  (H6000),  it  is  a  natural  candidate  for 
interface  with  AFIRMS. 
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(6)  Mini-Dyna-METRIC.  Much  of  AFIRMS  will  run  on  small  computers. 
Because  of  this,  the  full  Dyna-METRIC  model  (17,000  lines  of 
FORTRAN  code)  is  not  a  feasible  solution  to  spares  modeling  for 
AFIRMS.  The  Mini-Dyna-METRIC  model  was  developed  as  an  answer 
to  limited  computer  space  and  was  found  to  be  reasonably 
accurate.  However,  the  assumptions  inherent  in  the  full 
Dyna-METRIC  model  are  also  embedded  in  the  Mini-Dyna-METRIC. 

These  assumptions  reduce  the  validity  of  combat  capability 
assessment.  The  Mini  Dyna-METRIC  model  is  under  consideration 
for  inclusion  into  AFIRMS.  Current  projections  are  to  install 
and  validate  Mini-Dyna-METRIC  on  a  Z100  series  microcomputer 
during  FY85.  This  will  enhance  its  applicability  to  AFIRMS. 

(7)  Logistics  Capability  Measurement  System  (LCMS).  LCMS  is  a 
logistical  planning  and  management  tool  used  by  HQ  USAF  for 
budgetary  decisions  and  out-year  projections.  It  uses  summary 
data  at  only  the  highest  level  of  the  command  structure  and  is 
not  particularly  suited  to  AFIRMS  purposes.  There  are,  however, 
areas  within  LCMS  of  interest  to  parts  of  AFIRMS.  These  are  the 
dollars  to  weapon  system  calculations  and  munitions  capabilities. 

(8)  Contingency  Operations/Mobility  Planning  and  Execution  System 
(COMPES) .  COMPES  is  an  Air  Force  unique  automated  system  which 
uses  standardized  software  and  procedures  that  improve 
efficiency  and  effectiveness  of  Air  Force  contingency  planning 
and  execution.  It  provides  a  coordinated  response  to  plans  and 
execution  actions  by  manpower  and  personnel,  logistics,  and 
operations  functions.  COMPES  automates  Air  Force  procedures  at 
major  commands  and  base  levels  to  select,  deploy,  and  monitor 
contingency  forces.  The  system  is  currently  operational  and  is 
used  for  contingency  and  crisis  planning.  This  information  is 

of  direct  relevance  to  AFIRMS  and  will  be  explored  in  more  depth. 

(9)  Core  Automated  Maintenance  System  (CAMS).  CAMS  is  an  Air  Staff 
directed  project  to  improve  management  and  utilization  of 
maintenance  resources  by  enhancing  and  standardizing  the  flow 
and  availability  of  ADP  logistics  information.  CAMS  will 
support  all  base-level  aircraft,  engines,  trainers,  support 
equipment,  test  equipment,  missiles,  munitions,  and 
communications-electronics  maintenance. 

(10)  Combat  Supply  System  (CSS).  CSS,  an  Air  Force  system,  is  a 
small  transportable  computer  system  designed  to  deploy  with  and 
provide  direct  supply  support  to  combat  forces.  It  functions  as 
an  extension  of  the  Standard  Base  Supply  System  (SBSS)  to 
perform  wartime  essential  processes  at  deployed  locations. 

(11)  Vehicle  Integrated  Management  System  (VIMS).  VIMS,  an  Air  Force 
system,  collects  base  level  vehicle  maintenance  performance 
data.  The  information  provided  through  VIMS  is  used  in  the 
vehicle  management  decision  making  process. 
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(12)  Airlift  Implementation  and  Monitoring  System  (AIMS).  AIMS  is  an 
automated  data  system  to  support  the  operation  and  management  of 
the  active  duty  MAC  airlift  force.  Additionally,  AIMS  is 
intended  to  support  the  MAC  transportation  organizations 
worldwide  with  current  aircraft  schedule  and  movement 
information. 


•si 


(13)  Military  Air  Integrated  Reporting  System  (MAIRS).  MAIRS  is  a 

MAC  System  to  provide  accurate  reporting  of  mission  movement  to 
ensure  effective  command  and  control  of  active  duty  units.  The 
reporting  system  is  designed  to  provide  HQ  MAC  with  the  basic 
data  required  to  assist  in  effectively  managing  MAC  airlift 
assets;  provide  MAC  wings  with  the  information  required  to 
flight  follow  their  aircraft;  enable  the  theater  ALCCs  and 
overseas  RSS/JRCC  to  flight  follow  aircraft  in  their  areas;  and 
provide  enroute  stations  with  advance  notification  of  aircraft 
arrivals  and  departures. 


(14)  Information  Processing  System  (IPS).  IPS  is  a  MAC  system  being 
procured  to  provide  automated  support  capabilities  which  will 
aid  MAC  personnel  in  performing  the  command  and  control 
functions  associated  with  the  execution  planning,  scheduling, 
and  execution  of  MAC'S  airlift  mission. 


(15)  Flow  Generator,  Version  3  (FLOGEN  III).  FLOGEN  III  is  the 
automated  mission  flow  generator  that  MAC  uses  to  plan  the 
mission  flows  for  MAC  Operational  Plans  (OPlans)  and  exercises. 

(16)  Airlift  Deployment  Analysis  System  (ADANS).  ADANS  is  the 
planned  replacement  for  FLOGEN  III,  described  above,  and  will 
perform  essentially  the  same  functions. 

(17)  Theatre  Airlift  Management  Systems  (TAMS).  TAMS  is  an 
in-theatre  mission  flow  (scheduling)  and  tracking  system  for 
deployed  MAC  aircraft. 


(18)  Force  Management  Information  System  (FMIS).  FMIS  is  a  secure, 

MAJCOM-level  ADP  system  containing  SAC  force  status  data  and  the 
SAC  command  and  control  database. 


j.  Transmit  intersite  messages.  The  AFIRMS  System  Specification  details 
the  intersite  message  requirements. 

k.  Collect  trends  and  averages  for  use  in  computations.  While  this 
function  may  support  the  function  "Aggregate,  Analyze  and  Present 
Data,"  other  uses  are  expected.  The  function  is  required  chiefly  for 
what-if  exercises.  For  those  exercises,  AFIRMS  supplies  averaged 
rates  of  change,  averaged  prices,  average  performance  to  predicted 
ratios,  etc.  These  may  or  may  not,  reside  in  a  single  routine.  A 
generalized  design  is  desirable. 
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Much  of  the  data  used  by  AFIRMS  is  stored  in  databases  as  is  all  of 
the  current  raw  data.  This  data  may  be  accessed  by  queries  and 
processed  by  ad  hoc  models.  The  extent  and  methods  for  these 
applications  are  established  in  the  System,  Subsystem,  and  Database 
Specifications. 

(1)  Provide  user  ad  hoc  queries  (local). 

(2)  Provide  user  ad  hoc  queries  (intersite)  as  qualified  in  the 
System  and  Subsystem  Specifications. 

(3)  Provide  user  ad  hoc  calculations  (local). 
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3.3  Inputs  -  Outputs. 

3.3.1  Input  Formats.  Some  of  the  formats  available  for  data  input  are 
defined  in  the  Product  Description  referenced  in  Section  1.  The  data  involved 
in  the  screens  is  documented  in  the  AFIRMS  Data  Requirements  Document  and 
Database  Specifications.  The  intersite  and  intrasite  interface  specifications 
are  detailed  in  the  System  and  Subsystem  Specifications,  respectively. 


3.3.2  Output  Formats.  The  formats  to  be  used  for  data  output  are  defined  in 
the  Product  Description  referenced  in  Section  1.  The  data  involved  is 
documented  in  the  AFIRMS  Data  Requirements  Document  and  Database 
Specifications.  The  intersite  and  intrasite  interface  specifications  are 
detailed  in  the  System  and  Subsystem  Specifications,  respectively. 


3.4  Database  Characteristics.  The  material  in  the  AFIRMS  Data  Requirements 
Document  provides  the  fundamental  description  of  the  database  data  elements. 
The  AFIRMS  Database  Specification  provides  design  considerations  related  to 
the  AFIRMS  database.  The  database  is  physically  characterized  as  follows: 


Bytes 

Number  of 

X  Growth 

(Initial) 

Accesses/Day 

/Year 

Wing 

2.9  megabytes 

2500 

10 

MAJCOM 

65  megabytes 

500 

15 

HQ  USAF 

205  megabytes 

300 

20 

3.5  Failure  Contingencies. 

3.5.1  Operational  AFIRMS  Redundancy.  Operational  AFIRMS  redundancy  refers  to 
the  precaution  taken  (redundant  hardware,  replication  of  databases  at  several 
locations,  ability  to  reconnect  hardware,  etc.)  to  permit  AFIRMS  to  continue 
operating  at  full  or  degraded  capability  when  a  failure(s)  occurs. 


CDRL  0023 


3-14/CHG  1 


wIisViiKS 


It  must  be  emphasized  that  operational  AFIRMS  is  a  hierarchical  collection  of 
individual  sites  and,  therefore,  barring  the  existence  of  alternate  communication  paths, 
the  loss  (or  partial  loss)  of  any  particular  site  will  have  two  impacts:  partial  or  complete 
loss  of  AFIRMS  at  the  site  itself,  and  reduction  in  performance  of  otherwise  unaffected 
AFIRMS  sites  higher  in  the  operational  system.  For  example,  loss  of  a  wing  site  means 
loss  of  (timely)  data  to  a  MAJCOM  site. 

The  degree  of  loss  is  a  function  of  the  designs  of  the  AFIRMS  sites  and  of  the  ability 
of  the  sites  to  communicate  with  each  other.  As  an  example,  suppose  the  design  of  each 
wing  AFIRMS  site  was  centered  about  a  single  computer  with  a  single  communications 
link  to  its  MAJCOM  AFIRMS  site  and  that  the  wing  and  MAJCOM  sites  shared  no  data, 
i.e.,  their  databases  were  non-overlapping.  In  this  case,  a  computer  failure  at  the  wing 
would:  cause  complete  loss  of  AFIRMS  at  the  wing  site  (and  provide  no  way  for  the 
MAJCOM  to  assist  the  wing);  make  access  by  the  MAJCOM  to  any  wing  data  extremely 
slow  if  not  impossible,  thereby  rendering  it  difficult  to  perform  aggregation  and 
sustainability  evaluations;  and,  impact  wing  timeliness  to  translate  tasking,  create 
schedules,  launch  aircraft,  etc. 

Clearly,  the  AFIRMS  design  concept  proposed  in  the  System  and  Subsystem 
Specifications  has  some  limitations  and  suggests  that  a  number  of  system  considerations 
are  necessary  to  achieve  an  acceptable  level  of  redundancy  within  economic  constraints. 
Some  specific  considerations  which  the  AFIRMS  Central  Node  Module  (CNA)  system 
architecture  accommodates  are: 

a.  Distribution  of  selected  database  entities,  DBMSs,  and  processing  power  to  one 
or  more  functional  area  workstations  (FAWs)  in  addition  to  the  central  database 
at  each  site. 

b.  Use  of  several  computers  at  a  single  site,  with  each  computer  sharing  a  portion 
of  the  AFIRMS  processing  for  that  site.  If  one  computer  fails,  the  application 
is  redistributed  among  the  remaining  computers. 

c.  Redundant  data  storage  provided  by  multiple  on-line  storage  devices  accessible 
by  multiple  processors  at  the  CNM. 


However,  by  specifying  the  data  that  is  required  to  flow  over  these  secondary  information 
gateways,  and  by  providing  the  system  functionality  required  to  implement  these  flows, 
two  problems  are  resolved: 

a.  Wing  functional  areas  can  report  directly  to  their  MAJCOM  USAF  when  their 
CNM  is  down.  Similarly,  functional  areas  at  the  wing  level  can  report  directly 
to  HQ  USAF  when  the  MAJCOM  site  is  down. 

b.  Deploying  squadrons/wings  also  use  these  secondary  information  flows  to  report 
required  data  to  the  receiving  command  hierarchy. 

In  both  of  these  cases,  modems  over  dial-up  lines,  using  encryption  devices  where 
necessary,  can  be  used  to  effect  communications  redundancy  and  effect  the  secondary 
information  flows. 

3.5.2  Database  Backup/System  Backups.  AFIRMS  established  policy  for  backup  frequency 
differs  from  site  to  site.  As  a  minimum,  however,  backups  to  tape  are  made  every  24 
hours.  Furthermore,  a  journal  log  of  database  entries  will  be  maintained  to  permit  the 
entire  database  to  be  recreated  if  a  computer  or  disk  fails.  The  Database  Management 
Systems  selected  for  AFIRMS  segment  implementations  will  provide  for  automatic 
generation  of  the  journal  log.  The  procedure  uses  the  most  recent  backup  plus  the  journal 
log  to  recreate  the  database.  Refer  to  the  Subsystem  Specifications  for  a  more  in-depth 
discussion  of  required  DbMS  support  software  functionalities. 

3.5.3  Fallback.  Fallback,  as  defined  here,  occurs  after  the  AFIRMS  redundancy 
mechanisms  have  failed,  that  is,  AFIRMS  is  totally  unavailable  to  the  owning  echelon. 
Under  these  circumstances,  the  decision  support  provided  by  AFIRMS  would  be  lost. 

Provision  is  made  at  each  AFIRMS  user  echelon  site  to  maintain  the  necessary 
equipment,  skills,  and  hardcopy  AFIRMS  products  to  carry  out  their  missions  should 
AFIRMS  fail  totally.  Therefore,  the  users  of  AFIRMS  must  provide: 

a.  Training  of  personnel  in  manual  methods  for  satisfying  basic  mission  needs. 

b.  Equipment  to  aid  personnel  in  their  manual  effort  (this  includes  greaseboards, 
markers,  hardcopy  AFIRMS  products,  etc.). 


c. 


A 


AFIRMS  operational  procedures  that  maximize  the  data  available  for  a  manual 
effort.  That  is,  selected  database  entities  must  be  hardcopied  to  ensure  that 
data  will  be  available  if  an  AFIRMS  failure  occurs.  The  extent  and  frequency 
of  hardcopy  backup  are  parameters  that  are  AFIRMS  site  dependent.  They  are 
related  to  the  perishability  of  the  data,  physical  accommodations  for  storage, 
etc. 


I 


3.6  Security.  AFIRMS  handles  data  up  to  and  including  the  TOP  SECRET  classification 
level.  It  handles  sensitive  unclassified  data.  Due  to  the  various  environments  and 
processing  requirements  at  the  wing,  MAJCOM  and  HQ  USAF  levels  of  operation,  the 
security  modes  of  operation  differ.  HQ  USAF  operates  in  the  TOP  SECRET  System  High 
Security  mode;  MAJCOMs  operate  in  the  TOP  SECRET  System  High  Security  Mode;  and, 
wings  operate  in  the  controlled  Security  mode  at  levels  of  classification  from  unclassified 
through  SECRET. 


Security  protection  is  provided  for  these  environments  by  utilizing  a  combination  of 
the  following  security  measures  in  accordance  with  AFR  205-16. 


zr~-. 
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Personnel  Security.  The  personnel  security  program  implemented  for  the 
AFIRMS  Program  adheres  to  the  provisions  in  DoD  Regulation  5200.2/AFR 
205-32  USAF  Personnel  Security  Program.  Personnel  access  controls  are 
implemented  for  the  AFIRMS  central  computer  facilities  and  remote  terminal 
areas. 


(1) 


Central  Computer  Facility.  Strict  personnel  access  controls  are 
implemented  to  ensure  that  only  personnel  who  require  access  to  the 
facility  and  possess  a  security  clearance  at  least  equal  to  the  highest 
classification  of  information  being  processed  or  openly  stored  at  the 
facility,  are  admitted. 


(2) 


Remote  Terminal  Area(s).  Authorization  for  access  to  and  use  of  remote 
terminals  devices,  is  based  on  an  individual's  duties,  his/her  need  to  use 
the  terminal,  and  possession  of  a  security  clearance  of  the  required  level. 


Physical  Security.  Measures  ensure  external  protection  for  AFIRMS  against 
unauthorized  access  to  the  central  computer  facility,  to  the  system  from 
remote  terminals,  and  to  data  storage  media. 


(1) 


Central  Computer  Facility.  Central  computer  facility  physical  security 
meets  the  requirements  established  for  the  highest  classification  and  all 
sensitivity  categories  of  data  that  are  either  in  the  ADPS  or  openly  stored. 


(2) 


Remote  Terminal  Area.  Physical  security  measures  at  remote  sites  fulfill 
the  minimum  requirements  for  the  highest  classification  of  information 
accessed  from  or  stored  at  the  site. 
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c.  Hardware  Security.  AFIRMS  system  hardware  meets  all  of  the  provisions 
recommended  in  DoD  5200.  28M,  ADP  Security  Manual,  for  hardware  security 
features. 

d.  Software  Security.  The  operating  systems  selected  for  use  meets  the  general 
software  security  requirements  stated  in  DoD  5200.  28M.  In  addition  to  the 
security  protection  features  contained  in  the  operating  systems,  a  combination 
of  system  and  application  software  protection  features  provide  the  following 
security  protections  to  comply  with  applicable  DoD  and  Air  Force  security 
policies. 

(1)  Access  Control  to  prevent  unauthorized  entry  to  systems,  files,  and 
programs. 

(2)  Error  surveillance  and  Alerts  to  recognize,  record,  and  indicate  misuse  of 
the  system. 

(3)  File  Security  to  prevent  unauthorized  access  or  alterations  to  files.  An 
automated  audit  trail  provides:  file  access  record,  how,  and  from  where 
the  access  was  initiated;  the  identity  of  the  person  or  process  that 
initiated  the  access;  and,  all  unauthorized  attempts. 

(4)  User  Monitoring  and  Isolation  to  ensure  the  user  has  access  to  only  the 
system  information  to  which  he  is  entitled. 

e.  System  Stability.  All  AFIRMS  components  operate  so  that  one  can 
automatically  or  administratively  detect  and  report  system  hardware  and 
software  malfunctions  in  time  to  reasonably  prevent  unauthorized  disclosure. 

f.  Data  Integrity.  Each  database,  file,  and  data  set/element  are  identified  with  an 
origin,  use,  and  an  explicitly  defined  set  of  access  controls.  These  access 
controls  are  based  on  classification,  sensitivity,  user  clearance,  and  established 
need-  to-k  now. 

g.  Communications  Security  (COMSEC).  Approved  COMSEC  equipment  are  used 
on  all  communications  circuits  passing  classified  information.  These 
equipments  are  installed  IAW  AFR  100-45  and  NACSIM  5203  and  secured  IAW 
AFKAG-l.  NBS  or  NSA  approved  data  encryption  devices  may  be  required  for 
transmission  of  sensitive  unclassified  data  depending  on  the  nature  of  the  data. 

h.  Emanations  Security  (EMSEC).  ADP  and  communications  equipment  utilized  to 
process  classified  material  at  AFIRMS  sites  is  TEMPEST  approved.  All 
equipment  will  be  installed  IAW  the  guidelines  stated  in  NACSIM  5203. 
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Procedural  Security.  Security  operating  procedures  meet  the  requirements  of  I 

AFR  205-1  and  205-16  and  include  the  following: 

(1)  System  Access  Controls 

(2)  File  Access  Controls 

(3)  Personnel  Access  Controls 

(4)  Security  Markings 

(5)  Protecting  Classified  Output 

(6)  Physical  Security 

(7)  Protection  of  Residual  Information 


SECTION  4.  DESIGN  DETAILS 


4.1  System  Description,  The  worldwide  operational  AFIRMS,  is  a  hierarchically 
structured  system  which  can  be  visualized  as  a  pyramid  of  distinct  operational  sites. 


Each  operational  site  performs  a  set  of  distinct,  yet  similar  functions  and  transmits 
information  upward  to  a  parent  site.  There  are  three  basic  levels  within  the  AFIRMS 
pyramid,  each  level  being  considered  as  an  AFIRMS  subsystem.  The  highest  level 
subsystem,  the  apex  of  the  pyramid,  is  the  HQ  USAF.  The  second  level  of  the  pyramid 
consists  of  the  MAJCOM  subsystems.  Each  MAJCOM  contains  an  AFIRMS  MAJCOM 
subsystem.  The  base  of  the  pyramid  is  composed  of  a  set  of  wing  subsystems.  Each  type 
of  wing  within  a  MAJCOM  contains  an  AFIRMS  wing  subsystem  which  is  connected 
logically  to  the  parent  MAJCOM. 


4.1.1  General  Description.  AFIRMS  consists  of  three  subsystems  that 
interrelate  and  communicate  to  provide  the  AFIRMS  capability.  The  subsystems, 
named  in  accordance  with  the  command  levels  they  are  to  serve,  are  the  HQ 
USAF,  MAJCOM  and  wing  subsystems. 

Each  subsystem  provides  appropriate  functionality  to  the  users  in  order  to 
support  their  primary  functions.  The  following  functions  are  provided,  to 
some  degree,  to  users  at  each  subsystem  level: 

a.  Provide  for  entering/retrieving  data  into/from  an  AFIRMS  database. 

b.  Display  information  concerning  readiness  and/or  budget  analysis  (not 
provided  at  wing  level). 

c.  Provide  hardcopy  outputs  of  displayed  data  on  request. 

d.  Provide  capability  to  conduct  what-if  or  trade-off  exercises  related 
to  readiness  questions  and/or  budgetary  questions  (not  provided  at 
wing  level). 

e.  Provide  capability  to  execute  ad  hoc  queries  against  the  database  at 
the  local  site.  (This  capability  will  be  for  special  users  only.) 


sites  is  based  upon  a  centralized  site  database  and  a  set  of  functional  area 
databases.  For  a  full  discussion  of  the  AFIRMS  system  architecture,  refer  to 
the  AFIRMS  System  Specification.  This  architecture  can  be  accomplished 
through  dedicated  or  shared  equipment  software  and  facilities  with  other  ADP 
systems. 

The  centralized  database  is  accessed  via  the  CNM.  Each  CNM  will  service 
one  or  more  functional  areas  and  will  share  the  centralized  database  with  any 
other  CNM  comprising  the  central  node. 
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4.1.3  Central  Node  Modules.  Each  CNM  possesses  the  following  characteristics 


a.  A  full  duplex  high  band  width  communications  path  to  each  on-line 
storage  device  that  has  any  part  of  the  centralized  database  resident 
upon  it. 

b.  One  or  more  high  band  width  full  duplex  communications  paths  to  one 
or  more  other  CNMs  comprising  the  central  node.  If  only  two  CNMs 
comprise  a  central  node,  two  communications  paths  between  the  two 
will  be  provided. 
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d. 


A  copy  of  the  DBMS  being  used  for  the  system.  The  processing  of  the  updates 
or  retrievals  from  the  centralized  database  will  be  distributed  between  the 
CNMs. 


Each  CNM  updates  the  databases  of  the  functional  areas  serviced  by  it  as  required. 
Each  CNM  also  transmits  the  data  updates  made  by  one  or  more  of  its  attached  functional 
areas  to  all  other  CNMs  for  update  of  their  associated  functional  area  database  as 
required. 


4.1.4  Functional  Area  Workstations.  Each  functional  area  has  an  intelligent  device 
containing  its  own  database  and  copies  of  software  for  that  functional  area's  is 
requirements. 

The  data  resident  on  the  functional  area  database  consists  of  update/read  and/or  read 
only  data  elements.  The  specific  resident  data  is  determined  by  the  data  needed  for  a 
functional  area's  normal  use.  When  a  functional  area  update  is  made,  the  update 
transaction  is  sent  to  the  central  node  to  allow  update  of  the  centralized  database  and  for 
synchronization  of  the  databases  of  other  functional  areas. 


4.1.5  Communications.  A  communications  path  is  provided  for  normal  communications 
with  a  higher/lower  level  site.  In  addition  to  this  normal  channel  which  is  shared  by  all 
CNMs  at  a  site,  each  CNM  has  an  alternate  on  cadi  path  to  the  higher  level  site.  This 
alternate  path  is  variable  in  nature  and  contains  software  capable  of  communicating  via  a 
variety  of  protocols  and  data  transmission  speeds. 

A  communications  path  is  provided  for  normal  communications  between  a  functional 
area  and  a  CNM.  In  addition  to  this  normal  channel,  each  functional  area  has  an  alternate 
on-call  path  of  communications  (such  as  a  dial-up  phone  line).  Each  CNM  maintains  the 
required  transceiving  equipment  to  accept  the  alternate  path  transmission.  It  is  possible 
for  the  functional  area  to  use  the  alternate  transmission  path  to  link  directly  to  a  CNM  at 
a  higher/lower  level  site. 
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4.L6  AF1RMS  Readiness  Assessment  Overview.  The  AFIRMS  methodology  is  based  on 
the  use  of  four  Basic  AFIRMS  Functions  to  carry  out  various  Applications  (User) 
Functions.  This  section  summarizes  the  roles  of  the  Basic  Functions  and  the  ways  in 
which  they  support  each  of  the  Applications  (User)  Functions. 


The  same  diagram  will  be  repeated  for  each  of  eight  different  Applications  (User) 
Functions.  In  each  of  the  appearances  of  the  diagram,  emphasized  words  and  arrows  will 
indicate  the  ways  in  which  basic  functions  are  tailored  to  provide  that  specific  user 
function. 


a.  Measure  (and  aggregate)  readiness  vs.  standard  tasking.  The  current  UNITREP 
system  routinely  performs  the  function  of  reporting  and  aggregating  readiness 
of  C-ratings.  This  procedure  is  well  established  and  tested.  Unfortunately,  it 
has  been  found  to  have  serious  shortcomings,  largely  because  it  is  limited  in  the 
factors  considered.  AFIRMS  will  provide  an  approach  which  overcomes  several 
of  the  problems  which  are  associated  with  the  approach  of  the  C-rating  system 
to  this  task.  That  is,  it  will  measure  readiness  in  terms  of  ability  to  perform 
tasking. 

As  Figure  4-1  illustrates,  the  procedure  is  a  simple  application  of  the  Basic 
AFIRMS  Functions.  That  is,  a  simple  tasking  and  a  simple  statement  of 
resources  are  compared  to  create  a  measure  of  readiness  based  on  ability  to 
perform  the  tasking.  The  following  paragraphs  examine  how  each  of  the 
AFIRMS  Basic  Functions  apply  to  this  Applications  (User)  Function. 

( 1)  Translate  Tasking.  The  tasking  used  as  a  standard  for  regularly  scheduled 
measurement  of  readiness  is  derived  from  the  current  WMP  or  other 
standard  tasking.  The  WMP,  however,  does  not  include  all  of  the 
information  which  AFIRMS  needs  to  process  tasking.  It  will  be  necessary, 
therefore,  to  provide  detailed  information  to  the  wing  and  squadron  levels 
on  mission  type,  mission  priority,  and  preferred  load  requirement.  Note 
that  this  data  does  not  need  to  accurately  forecast  actual  missions  since 
the  objective  is  to  provide  a  consistent  standard  of  measure  for  repeated 
use.  The  identification  of  this  addition  of  data  is  made  outside  the 
mainstream  of  AFIRMS,  with  interactive  assistance  from  AFIRMS.  The 
results  are  stored  once  in  the  appropriate  AFIRMS  sites  and  recalled  and 
used  on  a  regularly  scheduled  basis. 
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Figure  4-1.  Measure  (and  Aggregate)  Readiness  vs.  Standard  Tasking 


(3)  Determine  Ability  to  Perform.  The  process  of  determining 
ability  to  perform  (for  Tactical  Fighter  Squadrons)  starts  by 
developing  a  draft  schedule  to  meet  the  tasking.  The  missions 
(sorties)  which  can  be  scheduled  within  the  resources  available 
constitute  the  basic  measure  of  readiness.  Since  this 
development  is  inherently  subject  to  error,  AFIRMS  regularly 
stores  both  the  forecast  number  of  sorties  and  the  number  of 
sorties  actually  generated  during  exercises.  The  ratio  of  these 
numbers  provide  a  measure  of  validation  and  a  basis  for 
adjustment  for  the  measure  resulting  from  the  direct  forecast  of 
the  schedule. 

(4)  Aggregate,  Analyze,  and  Present  Data.  Various  ways  of  stating 
readiness  are  required  depending  on  the  functional  perspective. 
At  each  level,  these  measures  are  based  on  aggregation  over 
subordinate  units  to  each  next  higher  level,  while  maintaining 
the  maximum  granularity  which  is  needed  by  any  higher  level.  To 
complete  the  development  of  useful  measurements,  each  echelon 
maintains  histories  of  the  results  of  these  calculations  to 
permit  the  plotting  and  analysis  of  trends  in  readiness. 
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For  the  regularly  scheduled  measurement  of  readiness,  the  Basic  AFIRMS  Functions 
consist  of:  the  retrieval  of  a  stored  standard  task  in  detailed  form;  the  use  of  data  on 
current  inventories;  the  calculation  and  adjustment  of  the  number  of  sorties  which  can  be 
flown;  and  the  aggregation  of  measures  to  higher  echelons  and  the  tracking  of  trends  in 
readiness. 


b.  Measure  (and  aggregate)  sustainability  vs.  standard  tasking.  AFIRMS  measures 
not  only  readiness,  but  sustainability.  As  with  readiness,  sustainability  is 
measured  on  a  regularly  scheduled  basis  against  standard  taskings.  The 
important  elements  appear  in  Figure  4-2.  A  discussion  in  terms  of  the  four 
Basic  AFIRMS  Functions  follows. 

(1)  Translate  Tasking.  The  process  of  translating  tasking  for  sustainability 
follows  that  for  readiness.  That  is,  it  requires  external  interpretation  to 
produce  a  standard  formatted  multi-day  tasking  which  is  accessed  each 
time  that  sustainability  is  to  be  evaluated. 

(2)  Define  Resources.  The  resource  balances  used  for  the  measurement  of 
sustainability  will  initially  be  those  used  for  readiness  measurement.  Two 
additional  factors,  however,  will  apply.  Expected  resupply  will  be  added 
to  resource  balances  at  the  end  of  each  day  and  the  balances  will  be 
reduced  by  the  expenditures  of  resources  as  calculated  in  the 
measurement  function.  These  changes  are  reflected  in  the  change  of 
name  of  the  arrow  from  box  2  to  box  3  and  in  the  introduction  of  a  new 
arrow  from  box  3  to  box  2.  The  calculation  of  consumption  may  be 
executed  in  part  by  other  systems.  For  example,  after  AFIRMS  develops 
a  schedule  for  the  day,  the  calculation  of  spares  consumption,  and  of  the 
resultant  shortfalls  may  be  performed  by  a  copy  of  Dyna-METRIC 
resident  on  another  system. 

(3)  Determine  Ability  to  Perform.  The  measurement  of  the  ability  to 
perform  will  be  exactly  as  described  for  measuring  readiness  except: 

(a)  Provisions  will  be  made  for  calculating  resource  usage  and  reporting 
the  results  to  the  Define  Resources  module. 

(b)  The  complete  procedure  will  be  cycled  for  the  number  of  days  over 
which  sustainability  is  being  measured. 

(4)  Aggregate,  Analyze,  and  Present  Data.  The  aggregation  and  tracking  of 
data  for  sustainability  is  equivalent  to  that  for  readiness  except  for  the 
added  dimension  of  "day  of  performance." 


Figure  4-2.  Measure  (and  Aggregate)  Sustainability  vs.  Standard  Tasking 


(4)  Aggregate,  Analyze,  and  Present  Data.  The  aggregation  and  tracking  of 
data  for  sustainability  is  equivalent  to  that  for  readiness  except  tor  the 
added  dimension  of  "day  of  performance." 

c.  Measure  (and  aggregate)  readiness  vs.  one-time  tasking.  The  tasking  used  by 

AFIRMS  will  not  always  be  a  standard  such  as  the  WMP.  For  planning  purposes, 
it  is  necessary  to  measure  readiness  for  actual  or  what-if  taskings.  A  discussion 
in  terms  of  the  four  Basic  AFIRMS  Functions  follows. 

(I)  Translate  Tasking.  The  translation  of  one-time  taskings  cannot  be 
retrieved  from  predefined  plans  as  with  standard  taskings.  Instead, 
AFIRMS  will  prompt  the  user  for: 

(a)  The  way  in  which  a  task  is  to  be  subdivided  and  detailed  to  the  wing 
level. 

(b)  Missing  elements  which  could  include  priorities,  choices  of 
munitions,  etc. 
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AFIRMS  makes  maximum  use  of  a  "building  block"  approach  to  constructing 
tasking  scenarios.  This  approach  speeds  the  what-if  tasking  definition  by 
permitting  judicious  mixing  and  matching  of  task  components.  Refer  to  the 
Transform  and  Model  Descriptions  document  for  a  detailed  discussion  of  this 
flexibility. 

Figure  4-3  illustrates  the  feedback  of  lessons  learned  from  capability 
assessments  to  the  redefinition  of  tasking  for  sensitivity  analysis  and/or 
analysis  of  alternative  tasking. 


Figure  4-3.  Measure  (and  Aggregate)  Readiness  vs.  One-Time  Tasking 


Once  the  tasking  is  in  a  form  which  can  be  evaluated,  the  other  two  Basic 
AFIRMS  Functions  are  performed.  Under  some  circumstances,  AFIRMS 
will  perform  predefined  reporting  functions  based  on  the  type  of  objective 
originally  specified  by  the  user,  (see  Figure  4-3  -  arrow  from  box  4  to  box 
1),  and  will  prompt  the  user  to  see  if  the  user  wishes  to  repeat  the 
evaluation  after  modifying  the  original  detailing  of  the  tasking  based  on 
this  new  data. 


(2) 


Define  Resources;  Determine  Ability  to  Perform;  Aggregate,  Analyze  and 
Present  Data.  These  other  Basic  AFIRMS  Functions  are  perf  ormed  as  for 
readiness  measurement  against  standard  tasking  except  that  no  trend  data 


is  collected  or  processed. 
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Measure  (and  aggregate)  sustainability  vs  one-time  tasking.  The  purpose  is 
essentially  the  same  as  for  the  measurement  of  readiness  vs.  one-time  tasking 
discussed  above  (see  Figure  4-4).  A  discussion  of  the  four  Basic  AFIRMS 
Functions  follows. 

Translate  Tasking  for  this  function  is  equivalent  to  that  for  the  measurement  of 
readiness  except  for  the  need  to  process  multiple  days.  The  same  distinction 
applies  to  the  other  three  AFIRMS  Basic  Functions.  Those  three  functions  are 
completely  analogous  to  those  used  to  measure  sustainability  against  standard 
tasking. 


Figure  4-4.  Measure  (and  Aggregate)  Sustainability  vs.  One-Time  Tasking 


Measure  (and  aggregate)  readiness  or  sustainability  vs.  revised  standards,  and/or 
revised  standard  tasking  using  historic  data.  As  the  Air  Force  improves  its 
posture,  several  factors  can  distort  the  comparisons  of  current  to  past 
readiness.  Two  of  these  are  that  the  standards  of  measurement  tend  to  be 
revised  upward  and  that  standard  taskings  are  subject  to  annual,  or  more 
frequent  revisions.  When  such  changes  have  occurred,  answers  to  the  question 
of  whether  the  Air  Force  is  in  fact  improving  its  capabilities  are  more 
complicated.  Under  the  UNITREP  system,  it  is  impossible  to  use  the  recorded 
C-ratings  to  recompute  the  capabilities  of  the  past. 


To  overcome  these  difficulties,  the  AFIRMS  system  retains  snapshots  of 
summary  resource  data  at  the  end  of  regular  periods.  Some  of  the  data  is 
retired  on  a  regular  schedule  so  that  the  coverage  of  recent  history  is  more 
frequent  than  that  for  the  more  distant  past.  Whether  the  retention  of  this 
historic  data  is  off-line  and  manual,  on-line  and  automatic,  or  some  procedure 
between  those  two  limits  depends  upon  the  needs  of  the  functional  user  and  the 
AFIRMS  organizational  level.  This  retention  and  recall  is  a  subfunction  of  the 
Basic  AFIRMS  Function  "Define  Resources."  Figure  4-5  shows  that  the  arrow 
from  box  2  to  box  3  is  concerned  with  this  historic  data,  and  also  notes  that  the 
software  performing  the  function  "Determine  Ability  to  Perform,"  may  have 
been  altered  to  conform  to  new  standards. 

The  retention  of  historic  data  cannot  provide  for  the  data  requirements 
introduced  by  fielding  of  new  resource  types.  Only  types  of  data  which  have 
been  collected  and  stored  can  be  recalled.  Procedures  for  using  default  values 
in  such  cases  will  require  consideration  in  individual  cases.  In  extreme  cases, 
the  problem  of  new  data  requirements  could  prevent  the  successful  execution 
and  comparative  reviews  of  historic  capabilities. 


Figure  4-5.  Measure  (and  Aggregate)  Readiness  or  Sustainability  vs. 
Revised  Standards,  and/^r  Revised  Standard  Tasking  Using  Historic  Data 
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Assist  in  allocaticy  of  resources  (physical  or  fiscal)-- forecast  results  of  trial  or 
final  allocation.  This  function  focuses  on  a  modification  of  the  way  in  which 
resources  are  defined.  In  this  case,  a  user  wishes  to  determine  the  impact  on 


capability  of  one  or  more  ways  of  allocating  either  dollar  or  material 
resources.  Figure  4-6  shows  that  the  focus  in  this  case  is  on  the  proposed 


allocation  and  on  a  feedback  of  the  capability  measurement  resulting  from  each 
trial. 


The  essential  function  for  AFIRMS  is  to  enable  the  user  to  input  assumptions, 
evaluate  the  result  and  report  the  capability  results  to  the  user  and,  if  desired, 
iterate  until  a  satisfactory  result  is  obtained.  It  would  increase  the  utility  of 
AFIRMS  if  it  were  able  to  offer  an  initial  allocation  as  a  starting  point  for 
subsequent  evaluation,  rejection,  alteration,  or  acceptance  by  the  user.  It  is 
important  to  note  that  the  only  correct  role  for  AFIRMS  is  that  of  a 
computerized  tool  which  is  available  for  use  when  the  user  wants  assistance. 
AFIRMS  itself  is  a  decision  support  tool,  not  a  decision  maker. 

The  Transform  and  Model  Descriptions  document  details  procedures  to  allow 
AFIRMS  to  suggest  a  near  optimal  allocation  of  newly  available  resources  to 
subunits.  This  may  be  used  to  provide  the  user  with  a  starting  point  if  he 
desires  one.  The  algorithm  is  discussed  further  in  Section  4.2.6. 


Figure  4-6.  Assist  in  Allocation  of  Resources  (Physical  or  Fiscal) 


Assist  in  task  assignment.  The  role  of  AFIRMS  in  task  assignment  is  directly 
comparable  to  its  role  in  resource  allocation.  That  is,  AFIRMS  offers  initial 
responses  to  problems  posed  by  the  user,  but  only  when  requested  to  do  so  by 
the  user.  In  all  cases,  AFIRMS  evaluates  solutions  posed  by  the  user,  whether 
or  not  they  relate  to  an  initial  response  developed  by  AFIRMS.  Figure  4-7 
illustrates  the  elements  of  this  function. 

In  this  function,  the  tasking,  rather  than  the  resources,  are  being  tested,  for 
that  reason,  the  "Translate  Tasking"  function  now  provides  the  what-ifs  to  be 
tested  and  receives  the  feedback  of  resulting  capabilities.  Thus  its  role  is 
analogous  to  the  role  played  by  "Define  Resources"  in  the  Resource  Allocation 
task. 

Proposed  taskings  in  detailed  form  are  provided  and,  after  the  ability  to 
perform  is  determined,  the  capabilities  and  the  resource  limitations  on  them 
are  fed  back  for  another  iteration  of  tasking  assignment.  Again  AFIRmS 
prompts  the  user  for  desired  changes,  and  may,  at  the  user's  request,  provide 
strawman  solutions. 
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Figure  4-7.  Assist  in  Task  Assignment 
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Assist  in  out-vear  budget  d  Ians— forecast  results  of  trial  or  final  allocations 


based  on  standard  or  user  supplied  assumptions.  There  are  a  number  of 
questions  related  to  out-year  budgets  which  can  be  posed.  The  questions  are 
listed  in  the  order  of  increasing  complexity.  In  fact,  each  of  the  last  two 
questions  subsumes  the  preceding  question.  Each  of  these  questions  requires 
that  the  user  specify  the  standard  tasking  to  be  used  as  a  basis  of 
measurement.  They  include: 


Based  on  existing  budget  plans,  what  capability  levels  will  be  obtained  in 
the  year  X? 


Assuming  an  increase  or  decrease  in  the  budget  for  year  X  of  amount  Y, 
what  is  the  best  use  of  the  new  funds  available? 


Assuming  an  increase  or  decrease  in  the  budget  for  year  X  of  amount  Y, 
what  changes  in  capability  levels  will  result  in  the  year  Z  (where  Z  may  or 
may  not  equal  X)? 


Each  of  these  questions  has  embedded  in  it  another  more  basic  question,  "Under 
the  assumed  conditions,  what  will  the  resources  available  be?"  As  Figur  4-8 
indicates,  the  emphasis  is  on  the  output  arrow  from  box  2,  "Define  Resources." 
If  the  resources  can  be  forecasted,  AFIRMS  will  perform  "Determine  Ability  to 
Perform"  and  provide  the  desired  capability  levels,  based  on  the  selected 
standard  tasking.  This  provides  the  answer  for  question  I  above. 


TRAMSIATC 

TASKING 


ACCBIGATI 
ANALTd  » 
PKCStNT  DATA 


OBTAIN  AND  APPLY  CAPABILITY  INFORMATION 


Figure  4-8.  Assist  in  Out-Year  Budget  Plans 


A  complicating  question  arises  concerning  the  degree  to  which  AFIRMS  will 
provide  the  estimated  resources  available.  As  part  of  the  POM  process, 
estimates  of  resources  are  developed  for  the  out-years.  However,  it  is  not 
clear  that  the  kind  of  detail  needed  for  a  valid  assessment  is  available  before 
Congressional  budget  revisions,  or  that,  if  it  is,  it  will  survive  Congressional 
actions.  For  purposes  of  clarification,  assume  that  the  answers  differ  for 
different  types  of  resources.  For  example,  the  data  on  aircraft  may  be  quite 
accurate  and  quite  detailed  (down  to  the  squadron  level)  while  other  items,  such 
as  levels  of  POL  by  type,  may  be  less  accurate  and  less  detailed,  especially  in 
terms  of  distribution.  Where  the  precise,  accurate  levels  are  available,  they 
must  be  fed  to  AFIRMS.  Where  such  answers  are  not  available  in  the  existing 
systems,  the  ability  to  generate  them  must  either  be  added  to  other  systems  or 
added  to  AFIRMS. 

As  noted  above,  once  AFIRMS  has  the  detailed  data,  it  directly  computes  the 
capability  level  needed  to  respond  to  Question  1  via  "Determine  Ability  to 
Perform." 

Question  2  builds  on  the  data  needed  for  Question  1.  Again,  it  is  necessary  that 
the  user  has  specified  the  standard  tasking.  Given  the  tasking,  and  the  detailed 
data  on  resources  available,  AFIRMS  can  calculate  which  resources  limit 
capability.  With  that  base,  AFIRMS  can  calculate  the  resources  which  will 
yield  the  greatest  increases  in  capability  per  dollars  expended.  (Or  the  least 
loss  per  dollar  for  a  loss  situation.)  This  statement  also  assumes  that  guidance 
has  been  provided  to  overcome  the  question  of  diverse  units  of  measure  (sorties, 
ton-miles  etc.). 

For  any  of  the  questions,  the  user  interaction  can  be  on-line  and  real-time.  For 
example,  a  total  funding  can  be  divided  among  the  MAJCOMS  by  the  user  (with 
bookkeeping  assistance  from  AFIRMS).  After  AFIRMS  provides  data  on 
proposed  resources  to  be  purchased  and  the  effect  on  capability  for  each 
MAJCOM,  against  that  MAJCOM's  basic  unit  of  measure,  the  user  can  then 
provide  the  human  judgement  as  to  desired  shifts  of  dollars  among  the 
MAJCOMs.  Again,  it  is  assumed  throughout  this  section  that  anything  AFIRMS 
provides  is  a  starting  point  subject  to  change,  rejection,  replacement  or 
acceptance  by  the  user. 

Question  2,  is  comparable  to  the  resource  allocation  problem  discussed  in  an 
earlier  section.  However,  the  process  is  applied  to  an  out-year  resource  status 
base  rather  than  to  the  existing  resource  status  base. 

There  are  other  caveats  required.  The  first  caveat  is  that  the  discussion  so  far 
has  implied  that  the  prices  of  the  resources  in  the  out-years  can  be  accurately 
estimated.  This  is  a  hazard  which  any  planner  faces  and  is  assumed  to  be 
acceptable.  The  second  caveat  concerns  the  assumption  that  the  resources  can 
be  caused  to  flow  in  immediate  response  to  the  expenditure  of  dollars.  For 
most  purposes  this  is  probably  true  for  out- years  if  the  user  applies  appropriate 
budgetary  "front  loading"  to  accommodate  the  procurement  logs. 


The  third  caveat  concerns  the  implied  assumption  that  dollars  spent  always 
translate  directly  into  more  resources  in  a  linear  way.  This  is  a  more  serious 
matter.  If  more  trained  airmen  are  to  be  available,  there  is  a  presumption  that 
there  is  a  complex  interrelationship  with  consumption  of  other  resources  used  in 
training. 

As  noted  earlier,  AFIRMS  may  be  able  to  refer  such  problems  to  other  systems 
already  used  in  the  POM  process. 

Question  3  can  now  be  examined  on  the  basis  of  Questions  1  and  2.  First  the 
starting  capability  is  determined  as  discussed  for  Question  1.  Then  the  user, 
with  help  from  AFIRMS  if  desired,  establishes  assumptions  about:  prices  of 
each  resource,  dollars  to  be  changed  (added  or  removed)  for  each  resource  so 
that  the  total  equals  the  required  change  in  the  total  budget  and,  distribution  of 
each  resource.  This  provides  a  new  "resource  available  status"  and  the  new 
capability  can  be  measured.  The  difference  between  the  old  and  the  new 
capability  compared  to  the  difference  in  dollars  provides  the  answer  to  the 
Congressionally  mandated  dollars  to  readiness  question. 

All  of  the  caveats  noted  for  Questions  I  and  2  apply.  There  are  presumably 
other  caveats  not  yet  noted.  One  is  known  and  deserves  brief  mention. 

If  the  responses  to  such  questions  in  one  year  are  to  be  comparable  to  those 
given  in  another,  the  year-to-year  changes  in  the  "standard  tasking"  such  as 
those  which  occur  in  the  WMP  need  to  be  accounted  for.  This  question  requires 
close  examination. 


An  interesting  point  arises  with  question  3.  It  concerns  the  distribution  of 
resources.  It  seems  unlikely  that  a  user  will  ever  settle  for  a  distribution  that 
shows  any  imbalance  due  to  either  mislocation  or  over/under  procurement  of 
some  items.  This  would  seem  likely  to  lead  to  answers  which  always  have  an 
optimistic  bias  since  such  perfection  is  unlikely  in  the  actual  event.  This  is  not 
a  question  of  human  failure,  but  rather  of  the  unpredictability  of  the  events 
which  cause  disruptions  in  balance  despite  any  conceivable  human  effort. 


Operational  AFIRMS  provides  one  method  of  dealing  with  this  problem.  The 
method  is  based  on  the  regular  computation  of  the  ratio  between  actual 
capability  (from  AFIRMS  looking  at  the  details  at  each  unit)  and  the  theoretical 
capability  if  all  resources  were  in  balance.  It  might  be  found  that  the  ratio 
stays  in  a  limited  range.  If  this  were  true,  the  ratio  could  be  used  as  an 
adjustment  to  counteract  the  optimistic  bias. 


It  should  be  noted  that  other  variations  on  these  basic  questions  can  be  posed. 
For  example,  they  can  be  asked  in  reverse.  For  question  3,  the  reverse  question 
is  "To  obtain  a  given  set  of  changes  in  capability,  what  changes  in  the  budget 
must  occur?" 


Further  analysis  is  required  to  establish  how  AFIRMS  will  obtain  the  required 
budgetary  data,  the  accuracy  of  that  data,  and  the  precise  models  needed  to 
process  the  data.  The  systems  to  which  AFIRMS  might  be  interfaced  have  not 
yet  been  identified.  The  significance  of  the  answers  when  the  data  available  is 


4-13 


used  for  this  purpose  has  not  been  tested  as  yet.  The  questions  requiring 
further  analysis  during  the  evolutionary  implementation  include  the  handling  of: 

(1)  Complex  interrelationships  among  variables. 

(2)  Maintenance  of  standard  tasking s  so  that  if  A  FI  RMS  is  asked  any  one  of 
the  three  questions  in  each  of  two  different  years,  the  response  will  be 
comparable  despite  the  difference  in  time. 

(3)  Procurement  lead  times. 


4.2  System  Functions.  The  Basic  AFIRMS  Functions  which  the  preceding  discussion  was 
based  upon  are  reviewed  in  Sections  4.2.1  through  4.2.6.  Accuracy,  validity,  and  timing 
considerations  accompany  the  discussions  of  each  of  the  component  functions. 


4.2.1  Overview  of  the  Basic  AFIRMS  Functions.  Figure  4-9  below  condenses  the  Basic 
AFIRMS  Functio  c  into  a  single  summarized  function.  That  is,  this  single  box  represents 
THE  Basic  AFIRMS  Function.  This  diagram  indicates  both: 


a.  The  basic  nature  of  AFIRMS  —  the  factors  which  differentiate  it  from  other 
systems. 

b.  The  absence  from  this  view  of  the  Secondary  AFIRMS  Functions  such  as 
providing  displays  of  inventory  status  and  the  Support  Functions  such  as  user 
interfaces,  communications,  etc. 
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Figure  4-9.  View  of  Single  AFIRMS  Function 


4.2. 1.1  What  This  View  of  AFIRMS  Is.  It  is  important  to  understand  the  specific  nature  of 
the  view  discussed  in  this  section.  This  view  attempts  to  isolate  and  focus  on  the 
functions  which  carry  out  the  fundamental  objectives  and  concepts  of  AFIRMS.  While 
there  are  many  objectives  of  AFIRMS,  most  of  them  are  supportive  of  the  central 
objective  which  is  to  improve  the  Air  Force's  ability  to  measure  capability  and  apply  the 
resulting  measures  to  serve  the  Air  Force. 

The  need  to  measure  traces  back  to  the  Air  Force  Chief  of  Staff's  tasking  to  "develop 
responsive  means  of  assessing  and  reporting  combat  capability."  The  need  to  apply  the 
results  is  exemplified  by  the  Congressional  mandate  to  deal  with  dollars  to  readiness. 

The  fundamental  concepts  of  AFIRMS  are: 

a.  Ability  to  perform  must  be  measured  in  terms  of  assigned  talking. 

b.  Ability  to  perform  must  be  measured  in  terms  of  resources  available  to  the 
individual  units  and  must  take  into  account  as  many  of  those  resources  as 
possible. 

c.  Capability  must  be  measured  in  terms  of  ability  to  perform. 

These  concepts  translate  directly  into  three  of  the  four  Basic  AFIRMS  Functions: 
Translate  Tasking,  Define  Resources,  and  Determine  Ability  to  Perform. 

4.2. 1.2  What  This  View  of  AFIRMS  Is  Not.  An  earlier  section  discussed  Applications 
(User)  Functions.  In  the  same  way,  this  section  focuses  on  the  Basic  AFIRMS  Functions. 

In  order  to  maintain  that  focus,  other  types  of  functions  are  not  stressed.  Functions  such 
as  providing  security  or  providing  communications,  referred  to  elsewhere  as  Support 
Functions,  are  generally  ignored.  This  is  not  because  they  lack  importance,  rather,  it  is 
to  permit  this  section  to  maintain  its  focus.  As  part  of  this  effort  to  maintain  focus,  only 
some  of  the  user  interfaces  which  may  occur  are  mentioned.  None  of  them  are  made 
specific  in  the  diagrams  which  illustrate  this  section.  In  particular,  the  fact  that  AFIRMS 
provides  prompts  in  obtaining  "Information  on  Resources"  or  "User  Assumptions,"  is  taken 
for  granted  in  order  to  focus  on  what  is  done  with,  or  about,  those  kinds  of  information 
once  they  are  available. 
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4.2, 1.3  Review  of  the  Overall  AF1RMS  Function.  Figure  4-9,  View  of  Single  AFIRWS 
Function,  is  repeated  below.  As  already  stated,  this  view  sees  AF1RMS  as  a  system 
devoted  to  obtaining  and  applying  capability  information.  This  is  reflected  in  the  title  of 
the  box.  It  is  also  reflected  in  the  two  outputs: 


The  output  "Capability  Assessments"  (top  arrow  on  the  right  of  the  box)  is 
driven  by  "User  Requirements"  (left  arrow  to  the  top  of  the  box)  accompanied 
by  "User  Criteria  and  Assumptions."  It  is  based  on  the  two  inputs,  "Information 
on  Resources^'  and  "Information  on  Standard  Tasks." 


The  other  output  "Proposals  on  Task  Assignments,  Resource  Allocation  etc." 
(bottom  arrow  on  the  right  of  the  box)  is  the  result  of  the  various  "assist"  type 
functions  discussed  in  the  last  section.  The  proposals  are  the  result  of  applying 
the  capability  information  AFIRMS  develops. 


The  following  pages  detail  this  view  in  a  non-rigorous  way.  A  more  rigorous 
presentation  of  the  material  on  which  this  section  is  based  appears  in  Appendix  A. 
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4.2.2  Breakdown  of  the  Overall  Basic  AF1RMS  Function  "Obtain  and  Apply  Capability 
Information."  As  Figure  4-10  indicates,  the  single  overall  function  just  discussed  is 
detailed  into  the  four  Basic  AFIRMS  Functions  which  have  been  discussed  in  preceding 
sections.  The  lower  diagram  is  a  "plug  compatible"  substitute  or  detailing  of  the  upper 
box.  The  complete  diagram  is  presented  here  to  provide  the  complete,  coherent  system 
structure  which  underlies  the  interfaces  shown  in  the  earlier  diagrams.  In  fact,  some 
interface  arrows  are  shown  which  were  not  discussed  as  part  of  the  simplified  diagrams. 

Since  several  variations  of  the  lower  diagram  have  been  discussed  on  earlier  pages, 
this  discussion  will  focus  on  the  nature  of  the  diagram  used,  rather  than  on  the  details  of 
the  diagram. 

At  first  sight,  the  lower  diagram  appears  to  be  (and  is)  quite  complex.  It  is,  however, 
an  overlay  of  the  more  simple  diagrams  presented  earlier.  A  few  interface  arrows  which 
were  omitted  there  as  not  central  to  understanding  the  process  have  been  added.  For  any 
given  AFIRMS  site,  it  is  unlikely  that  all  of  the  arrows  or  boxes  shown  in  Figure  4-10 
would  ever  be  activated  simultaneously.  AFIRMS  is,  however,  intended  to  be  a  worldwide 
system.  That  system  will  consist  of  many  computers.  At  any  moment,  each  of  those 
computers  may  be  involved  in  one  or  more  of  the  overall  system  functions  which  implies 
that  any  of  the  arrows  may  be  active.  It  is  important  that  subordinate  views,  such  as 
those  used  when  discussing  the  Applications  (User)  Functions,  be  drawn  from  a  complete, 
coherent  functional  architecture  of  the  system. 
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The  architecture  shown  does  not  focus  on  either  the  echelons  involved  or  the 


hardware  selected.  The  intent  is  to  clarify  the  overall  functions  first,  and  only  when  that 
clarification  is  complete,  to  assign  portions  of  each  of  the  functions  to  appropriate  levels 
for  implementation.  While  some  of  the  assignments  are  obvious,  the  ultimate  location  of 
performance  for  some  of  the  subfunctions  will  be  determined  during  the  final  design 
process. 

The  type  of  projection  shown  graphically  in  Figure  4-10  reflects  a  requirement  that 
the  lower  diagram  must  display  all  of  the  subfunctions  of  the  upper  box.  This  type  of 
projection  is  not  shown  graphically  in  the  rest  of  this  section.  It  is  however,  to  be 
inferred.  The  function  "Translate  Tasking"  is  a  detailing  of  box  one  in  the  lower  diagram 
of  Figure  4-10,  the  function  "Define  Resources"  is  a  detailing  of  box  two  of  Figure  4-10 
and  so  on  for  the  other  two  Basic  AFIRMS  Functions. 


4.2.3  The  Basic  AF1RMS  Function  "Translate  Tasking."  As  Figure  4-1  I  indicates,  the 
Basic  AFIRMS  Function  "Translate  Tasking"  consists  of  four  subfunctions.  For  many 
applications,  only  one  of  them  will  be  active.  Figure  4-12  shows  that  condition. 


Figure  4-11.  Translate  Tasking 


31971 


4-21 


AD-A178  521  AIR  FORCE  INTEGRATED  READINESS  MEASUREMENT  SVSTEN  2/2 

(AFIRMS)  FUNCTIONAL  DESCRIPTIONS)  SOFTECH  INCL 
ALEXANDRIA  VA  28  SEP  85  F49642-82-C-8822 


UNCLASSIFIED 


F/G  5/2 


NL 


3c 


Cl 


comrute 
TASKING  0* 
NAME  OR - „ 

rro 


USER  REQUIREMENT* 
ROR  INFORMATION  WITH 
USER  CRITERIA.  ( 
ASSUMPTIONS 


STO. 

TASKINC 


SELECT  OR 
PASS  ON 
TASKINC 


SfLSCTSO  OR 
TRANSMITTED 
SASIC  TASKINC 


TASKING  IN 

DETAILED 

FORM 


•  I 


Figure  4-12.  Select  or  Pass  on  Tasking 


4.2.3. 1  Processing  oi  Detailed  Tasking.  The  subfunction  represented  by  Figure  4-12, 
always  begins  by  performing  the  steps  necessary  to  ensure  a  valid  initiation.  That  is,  any 
prompting  and  editing  necessary  to  establish  an  acceptable  tasking  input  followed  by  a 
review  of  the  user  authority  to  be  sure  the  user  may  submit  such  a  task.  Some  of  these 
initiations  may  have  a  stored  schedule  as  a  user.  The  wings,  for  example,  are  expected  to 
evaluate  their  capability  regularly  without  requiring  a  special  input  by  any  user. 
Depending  on  the  application,  this  step  may  occur  at  any  echelon. 

If  a  valid  initiation  provides  a  tasking  in  one  of  the  formats  expected  by  AFIRMS,  ail 
or  parts  of  the  tasking,  are  distributed  to  the  relevant  sites.  At  that  point,  the 
subfunction  represented  by  Figure  4-12,  can  play  either  of  two  roles. 


The  first  role,  "Selec*  Tasking,"  occurs  whenever  the  user  specified  tasking  is  a 
standard  tasking  known  to  the  system,  in  that  case,  a  prestored,  detailed  form  of  the 
standard  as  it  applies  to  each  unit,  is  retrieved  from  storage  and  presented  to  the 
"Determine  Ability  to  Perform"  function  for  processing. 


The  second  role,  "Pass  on  Tasking,"  occurs  whenever  the  user  specified  tasking  is  a 
one-time  tasking  presented  in  the  detailed  format  necessary  for  processing  by  AFIRMS. 
In  that  case,  the  detailed  form  of  the  tasking  supplied  is  presented  to  the  "Determine 
Ability  to  Perform"  function  for  processing. 
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When  the  box  4  function  "Compare  Results  to  User  Needs,"  is  to  be 
activated,  the  result  of  the  assessment  is  fed  back  and  compared  to  the  user's 
objectives  (box  4).  The  resulting  evaluation  of  the  existing  detailing  of  the 
tasking  is  fed  back  as  assistance  for  deciding  whether  to  accept  the  existing 
detailing  or,  if  not,  what  revisions  are  to  be  made  before  the  next  trial. 

This  subfunction  may,  or  may  not  be  fully  or  partially  automated. 


4. 2. 3. 3  Performance  Requirements.  Tasking  is  expressed  in  numbers  of 
missions,  sorties,  and  sortie  duration.  These  facts  establish  that  integer 
precision  is  required.  Data  accuracy  is  critical.  Elements  of  the  input 
function  occur  at  all  echelons.  Some  standard  tasking  data  will  be  in  use  for 
as  much  as  a  year.  AFIRMS  recognizes  and  questions  normal  annual  dates  at 
which  new  standard  tasking  is  to  be  expected.  Ad  hoc  tasking  is  retained 
on-line  for  a  period  established  by  the  System  Manager  in  accordance  with 
local  operating  procedures.  During  peacetime,  AFIRMS  provides  assistance  with 
tasking  based  on  training  needs. 


4.2.4  The  Basic  AFIRMS  Function  "Define  Resources."  As  Figure  4-13 
indicates,  the  Basic  AFIRMS  Function  "Define  Resources"  can  be  detailed  in 
five  subfunctions.  The  five  subfunctions  can  be  seen  as  three  groups;  one 
dealing  with  the  past;  one  dealing  with  the  present;  and,  one  dealing  with  the 
future. 
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The  Present.  The  simplest  group  deals  with  the  present.  It  is  represented  in 
Figure  4-14  by  box  1,  "Track  Current  Resource  Status."  This  is  a  complete 
inventory  system  for  the  types  of  resources  considered  by  AFIRMS.  The  system 
must  know,  not  only  the  current  balances  on-hand  at  the  wing,  but  also 
resources  at  all  echelons  as  well  as  the  "pipeline*'  of  planned  movements  and 
repairs.  Wherever  possible,  AFIRMS  uses  the  services  of  other  systems  to 
provide  this  inventory,  collecting  only  the  current  or  projected  status  as  it  is 
needed.  Note  that  the  inventory  information  may  change  over  the  life  of 
AFIRMS.  That  is,  as  new  systems  become  available,  data  on  resources  which 
AFIRMS  once  tracked  is  obtained  from  these  new  systems. 

Where  AFIRMS  itself  does  the  inventory  tracking,  every  effort  is  made  to  make 
the  information  retained  useful  to  those  who  supply  it.  This  is  done  to 
encourage  prompt  and  accurate  updates. 

The  Past.  Another  simple  group  deals  with  the  past.  It  is  shown  in  Figure 
4-14.  On  a  regular  basis,  the  current  data  from  box  1  is  captured  by  box  2. 

Upon  user  request,  the  data  is  recovered  and  provides  the  "Resources  Available" 
interface  supplied  to  "Determine  Ability  to  Perform." 
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Figure  4-14.  Subfunctions  of  Defined  Resources 


The  Future.  The  final  group  deals  with  the  future  and,  consists  of  all  the  boxes 
except  box  2.  Starting  with  the  current  status  from  box  1,  AFIRMS  first 
forecasts  the  changes  to  occur  in  total  inventory  before  the  start  of  a  future 
capability  assessment.  The  expected  distribution  over  units  is  then  determined 
to  provide  the  distributed  "Resources  Available"  to  be  available  to  the 
"Determine  Ability  to  Perform"  function.  The  final  subfunction,  box  5,  is 
comparable  to  the  final  box  discussed  for  "Translate  Tasking."  That  is,  it  is 
concerned  with  noting  areas  of  possible  improvement  should  further  iterations 
be  desired. 

Section  4.1.6  mentioned  an  algorithm  to  generate  an  initial  proposal.  The 
discussion  in  that  section  on  the  proper  role  for  AFIRMS  is  repeated  here  as  a 
preliminary  to  the  discussion  of  the  algorithm. 
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The  Present.  The  simplest  group  deals  with  the  present.  It  is  represented  in 
Figure  4-14  by  box  1,  "Track  Current  Resource  Status."  This  is  a  complete 
inventory  system  for  the  types  of  resources  considered  by  AFIRMS.  The  system 
must  know,  not  only  the  current  balances  on-hand  at  the  wing,  but  also 
resources  at  all  echelons  as  well  as  the  "pipeline"  of  planned  movements  and 
repairs.  Wherever  possible,  AFIRMS  uses  the  services  of  other  systems  to 
provide  this  inventory,  collecting  only  the  current  or  projected  status  as  it  is 
needed.  Note  that  the  inventory  information  may  change  over  the  life  of 
AFIRMS.  That  is,  as  new  systems  become  available,  data  on  resources  which 
AFIRMS  once  tracked  is  obtained  from  these  new  systems. 

Where  AFIRMS  itself  does  the  inventory  tracking,  every  effort  is  made  to  make 
the  information  retained  useful  to  those  who  supply  it.  This  is  done  to 
encourage  prompt  and  accurate  updates. 

b.  The  Past.  Another  simple  group  deals  with  the  past.  It  is  shown  in  Figure 
4-14.  On  a  regular  basis,  the  current  data  from  box  l  is  captured  by  box  2. 

Upon  user  request,  the  data  is  recovered  and  provides  the  "Resources  Available" 
interface  supplied  to  "Determine  Ability  to  Perform." 
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Figure  4-14.  Subfunctions  of  Define  Resources 


c.  The  Future.  The  final  group  deals  with  the  future  and,  consists  of  all  the  boxes 
except  box  2.  Starting  with  the  current  status  from  box  I,  AFIRMS  first 
forecasts  the  changes  to  occur  in  total  inventory  before  the  start  of  a  future 
capability  assessment.  The  expected  distribution  over  units  is  then  determined 
to  provide  the  distributed  "Resources  Available"  to  be  available  to  the 
"Determine  Ability  to  Perform"  function.  The  final  subfunction,  box  5,  is 
comparable  to  the  final  box  discussed  for  "Translate  Tasking."  That  is,  it  is 
concerned  with  noting  areas  of  possible  improvement  should  further  iterations 
be  desired. 

Section  4.1.6  mentioned  an  algorithm  to  generate  an  initial  proposal.  The 
discussion  in  that  section  on  the  proper  role  for  AFIRMS  is  repeated  here  as  a 
preliminary  to  the  discussion  of  the  algorithm. 


The  essential  function  for  AFIRMS  is  to  enable  the  user  to  input  assumptions, 
evaluate  the  result,  report  the  capability  results  to  the  user,  and  if  desired, 
iterate  until  a  satisfactory  result  is  obtained. 

AFIRMS  utility  is  increased  by  providing  an  initial  allocation  as  a  starting  point 
for  subsequent  evaluation,  rejection,  alteration,  or  acceptance  by  the  user.  It  is 
important  to  note  that  the  only  correct  role  for  AFIRMS  is  that  of  a 
computerized  tool  which  is  available  for  use  when,  and  only  when,  the  user 
wants  assistance.  AFIRMS  itself  is  not  a  decision  maker. 

The  Transform  and  Model  Descriptions  document  details  a  procedure  to  allow 
AFIRMS  to  suggest  a  near  optimal  allocation  of  newly  available  resources  to 
subunits.  A  discussion  of  the  algorithm  follows. 

The  resources  to  be  allocated  are  over  and  above  the  amounts  currently 
considered  to  be  on-hand  or  in  the  pipeline.  The  resources  are  "hard,"  that  is, 
dollars  are  not  considered.  Assume  for  example  that  a  supply  of  fuel  and  a 
supply  of  munitions  has  just  become  available  (perhaps  diverted  by  a  higher 
command  from  another  theatre).  The  question,  then,  is  given  a  number  of 
resources  and  an  amount  of  each,  what  is  a  near-optimal  allocation? 

The  optimization  criterion  is  the  number  of  sorties  giving  greatest  weight  to 
the  earliest  day  (and  within  each  day  to  the  highest  priority).  Each  priority  is 
assumed,  by  implication,  to  have  only  one  sortie  type  per  subunit  per  priority. 

This  algorithm  is  intended  to  illustrate  one  of  many  that  could  be  used,  and  is 
subject  to  possible  refinements.  Refinements  include: 

(1)  Adding  user  constraints  (send  no  fuel  to  Wing  X). 

(2)  Allowing  for  storage  and/or  transportation  limits. 

(3)  Allowing  delays  in  first  deliveries  to  account  for  time  in  transit. 

(4)  Differentiating  between  consumable  resources  (e.g.  fuel)  and 
non-consumable  resources  (e.g.  aircraft). 

(5)  Major  changes  in  the  algorithm  would  occur  for  changes  and  additions 
such  as: 

(a)  Changing  the  optimization  criterion,  perhaps  optimizing  total 
sorties  without  priority  rating  or  another  alternate  objective. 

(b)  Providing  for  interunit  transfer  of  resources. 

(6)  Dealing  with  dollar  resources  in  addition  to,  or  instead  of,  only 
considering  hard  resources. 

When  dollars  only  are  allocated,  the  algorithm  would  be  simplified  to  one  which 
determines  the  shortfalls  and  allocates  money  to  their  removal  in  priority 
order. 
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!  The  algorithm  for  the  stated  problem  starts  by  providing  resources  for  all  of  the 

J  .  days  in  which  other  constraints  (tasking  limits  or  shortfalls  in  other  resources) 

\  'v'v  prevent  exhaustion  of  the  available  supplies.  The  resources  are  simply 

allocated  to  the  units  to  fill  their  added  consumption. 

[  When  a  day  and  priority  is  reached  for  which  one  or  more  resources  would  be 

exhausted,  a  simplifying  assumption  is  made  to  establish  a  linear  problem.  The 
resultant  problem  is  a  classic  case  of  contention  for  resources  among  possible 
uses.  A  simplex  array  is  constructed  and  solved.  Since  the  real  situation 
involves  nonlinear  consumption,  the  solution  may  be  suboptimal.  The  saving  in 
|  computation  appears  intuitively  to  be  worth  any  loss  of  theoretical  optimality. 

Should  that  assumption  prove  inaccurate,  a  step-wise  solution  will  provide  a 
precise  solution. 

Under  the  control  of  the  user  interface  system,  the  user  is  offered  a  variety  of 
algorithms.  The  first  is  to  omit  any  machine  generated  suggestions.  Others 
match  various  possible  user  objectives  and  the  varying  amounts  of  time  users 
may  wish  to  devote  to  the  topic.  For  example,  stopping  at  the  end  of  the  first 
step  in  the  algorithm  just  discussed,  determining  what  distribution  can  occur 
before  contention  arises,  may  be  more  useful  than  continuing  through  an  effort 
to  optimize  the  last  part  of  the  distribution. 

The -distribution  of  resources  can  be  processed  at  a  central  site,  or  to  take 
advantage  of  distributed  human  knowledge  and  distributed  processing  power,  it 
can  be  processed  by  command  level.  That  is,  HQ  USAF  will  pass  assumptions  or 
questions  about  distribution  to  the  MA3COM  which,  in  turn,  will  pass  questions 
and  its  added  assumptions  to  the  wing. 

4.2.4. 1  Performance  Requirements.  As  noted,  this  function  requires  information  of  wing, 
MA3COM,  and  HQ  USAF  stocks.  For  major  what-if  exercises  processed  in  distributed 
mode,  coordinated  inputs  by  many  users  may  be  desired  to  avoid  a  bottleneck  caused  by 
entering  all  of  the  data  and  assumptions  at  one  site. 


The  precision  required  is  usually  integers.  The  accuracy  varies  by  type  of  resource, 
and  is  be  detailed  in  the  DRD.  Timeliness  is  addressed  in  the  System  and  Database 
Specifications,  however,  it  is  to  be  expected  that  data  which  is  brought  to  a  current  state 
twice  daily  will  meet  the  normal  needs  of  AFIRMS.  It  is  also  expected  that  other  uses  in 
the  wing  will  gradually  lead  to  data  being  available  which  is  more  current  than  that  just 
specified. 
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4.2.5  The  Basic  AFIRMS  Function  "Determine  Ability  to  Perform."  The  Basic  AFIRMS 
Function  "Determine  Ability  to  Perform"  is  the  center  of  the  AFIRMS  system.  As  Figure 
4-15  indicates,  this  function  includes  three  subfunctions. 


The  first  function  is  the  generation  of  some  level  of  schedule  for  the  wing.  The 
generation  of  the  schedule  requires  that  the  actual  condition  of  the  wing  be  considered, 
and  thereby  enforces  a  realistic  evaluation  of  the  wing's  capability. 
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Figure  4-15.  Determine  Ability  to  Perform 


The  process  of  scheduling  is  performed  automatically  to  allow  regular  assessments  of 
wing  capability  which  may  cover  spans  of  up  to  90  days  each  with  an  individual  schedule. 
The  results  for  the  current  day  against  current  tasking  will,  however,  be  made  available  to 
the  wing  as  a  starting  point  for  iterative  improvement.  This  is  done  both  as  a  service  to 
the  wing  and  to  evoke  comments  on  the  reality  of  the  scheduling  being  done  by  AFIRMS. 
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The  "Analyze"  function  stores  capability  assessments,  computes  statistics  such  as 
trend  lines,  moving  averages  or  standard  deviations,  and  provides  exception  type  reports 
based  on  changes  which  are  considered  significant  to  the  functional  users. 

The  "Aggregate'1  function  deals  with  the  accumulation  of  wing  capability  data  to 
provide  measures  at  the  MAJCOM  level  and  of  MAJCOM  data  to  provide  measures  at  the 
HQ  USAF. 
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Figure  4-16.  Aggregate,  Analyze  and  Present  Data 
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a.  Aggregation.  It  is  part  of  our  folklore  that  adding  is  simple,  but 

that  adding  apples  and  oranges  is  impossible.  So  the  question  for  V* 

AFIRMS  is,  "How  are  results  added  when  the  units  of  measure 
considered  are  not  identical?"  The  primary  AFIRMS  capability 
assessment  metric  was  specifically  selected  to  address  this  issue. 

There  are  two  components  to  this  issue. 

(1)  The  first  step  deals  with,  "How  can  AFIRMS  aggregate  nearly 
identical  units  of  measure  which  occur  in  subcategories  (such 
different  missions  within  a  "mission  area"  category  such  as 
tactical  fighter/reconnaissance).  In  this  case,  capability 
assessments  can  be  aggregated  along  mission  lines.  This 
approach  provides  visibility  of  capability  with  an  aggregation 
appropriate  to  the  needs  of  each  command  level. 


At  the  unit  level,  capability  can  be  viewed  at  the  discrete 
sortie  level  for  generation  assessments  by  mission  type,  i.e., 
at  the  AFIRMS  mission  metric  level.  At  MAJCOM  or  other 
intermediate  headquarters,  this  "atomic"  unit  of  measure  for 
combat  capability  can  be  aggregated  as  unit  mission  capability 
assessments.  For  example,  assessments  can  be  evaluated  at  the 
ATO/frag  level  (with  multiple  concurrent  sorties  in  a  mission  at 
one  unit)  for  fighter/reconnaissance  units,  or  at  the  system 
mission  level  for  MAC  (multiple,  sequential  missions  with 
portions  of  the  tasking  accomplished  by  different  units). 
Finally,  at  the  Air  Staff  level,  the  AFIRMS  assessments  can  be 
aggregated  for  assessment  of  mission  area  capability,  such  as 
strategic  bombers,  strategic  airlift,  or  tactical 
fighter/reconnaissance. 


Note  in  this  approach  that  the  capability  assessments  must  be 
available  to  each  command  level  as  assessments  at  the  lowest 
level  of  AFIRMS  metric  detail  so  that  the  capability  aggregation 
at  each  level  can  be  decomposed  for  analysis  into  their 
component  parts  by  command,  mission  type,  and  so  forth. 


(2)  The  second  component  of  the  aggregation  issue  deals  with 
aggregation  of  various  kinds  of  capabilities  such  as  very 
different  types  of  missions.  For  disparate  capabilities  such  as 
fighter/reconnaissance  and  strategic  airlift  capabilities, 
aggregation  should  consist  simply  of  reporting  both  (or  all) 
numbers.  This  maintains  the  tasking  orientation  of  the 
capability  assessments.  If,  however,  an  overall  rating  is 
desired  (such  as  a  readiness  rating  supplementing  the  C-rating 
system),  mission  capabilities  can  be  added  as  sorties  across 
missions  to  provide  mission  independent  capability  assessments 
independent  of  the  mission  area. 


The  AFIRMS  capability  assessment  metric  "mission"  is  uniquely  defined 
to  accommodate  both  roles  as  well  as  provide  the  basis  for  derivation 
of  any  functional  views  (metrics  such  as  sorties,  alert  sorties, 
flying  hours,  ton-miles,  and  dollars). 
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4.3  Flexibility. 


a.  AFIRMS  is  flexible  in  several  senses: 


(1)  Over  MAJCOMs.  MAJCOMs  manifestly  differ  in  missions,  objective 
measures  of  performance,  'and  organizations.  Systems  which  might 
interface  with,  or  perform  functions  of  AFIRMS  vary.  User 
attitudes  also  vary. 

(2)  Over  geography.  Locations  of  sites  imply  different 
requirements.  At  a  minimum,  maps  used  in  displays  require 
adjustment . 

(3)  Over  organization.  As  with  MAJCOMs,  the  organization  within 
which  each  site  is  located  requires: 

(a)  Availability  of  options  to  adjust  to  the  unit's  "way  of 
doing  things"; 

(b)  Adjustment  to  the  systems  in  use  by  the  organization  which 
can  serve  as  data  sources;  and, 
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a.  Aggregation.  It  is  part  of  our  folklore  that  adding  is  simple,  but  that  adding 

apples  and  oranges  is  impossible.  So  the  question  for  AFIRMS  is,  "How  are  results 
added  when  the  units  of  measure  considered  are  not  identical?" 

The  first  step  deals  with,  "How  can  AF1RMS  aggregate  nearly  identical  units  of 
measure  (such  as  sorties)  which  occur  in  subcategories  (such  as  sorties  using 
different  weapon  systems  or  sorties  of  different  mission  types)?  Most 
particularly,  is  it  possible  to  plan  a  general  approach  which  will  be  adaptable  to 
the  inevitable  future  changes  in  needs?" 

The  current  approach  for  the  reporting  of  sorties  on  operational  AFIRMS  is  that, 
for  sustainability  measurements,  the  data  passed  would  include: 

(1)  "Unit,"  'Tasking  Identification,"  "Day  of  Measurement,"  "What-if 
classification  of  the  data  passed,"  and,  'Time  of  Evaluation."  This  data  would 
be  defined  once  for  each  evaluation. 

(2)  "Day  within  tasking  period,"  (This  element  would  not  have  a  value  greater 
than  one  for  measurements  of  readiness),  "Weapon  System,"  and  "Sortie  Type." 

The  discussion  points  out  that  a  way  of  providing  flexibility  in  this  regard  can  be 
established.  In  view  of  the  changeable  environment  in  which  systems  exist, 
AFIRMS  must  possess  that  flexibility. 

The  second  step  deals  with  aggregation  of  various  units  of  measure  such  as  sorties 
and  ton-miles.  For  disparate  measures  such  as  sorties  and  ton-miles,  aggregation 
should  consist  simply  of  reporting  both  (or  all)  numbers. 


4.3  Flexibility. 


a.  AFIRMS  is  flexible  in  several  senses: 

(1)  Over  MAJCOMs.  MAJCOMs  manifestly  differ  in  missions,  objective 
measures  of  performance,  and  organizations.  Systems  which  might 
interface  with,  or  perform  functions  of  AFIRMS  vary.  User  attitudes  also 
vary. 

(2)  Over  geography.  Locations  of  sites  imply  different  requirements.  At  a 
minimum,  maps  used  in  displays  require  adjustment. 

(3)  Over  organization.  As  with  MAJCOMs,  the  organization  within  which 
each  site  is  located  requires: 

(a)  Availability  of  options  to  adjust  to  the  unit's  "way  of  doing  things"; 

(b)  Adjustment  to  the  systems  in  use  by  the  organization  which  can 
serve  as  data  sources;  and, 
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(4)  Over  time.  To  make  AFIRMS  as  economical  as  possible,  the  following 
adjustments  are  accommodated: 

(a)  Running  additional  systems  (non-AFIRMS)  on  AFIRMS  equipment  or 
vice  versus; 

(b)  Using  equipment  "belonging"  to  other  systems  to  host  AFIRMS. 

(c)  A  phased  implementation  is  planned. 

(5)  Over  equipment.  AFIRMS  is  impacted  by  several  kinds  of  equipment 
changes: 

(a)  Replacement  (at  some  bases)  of  obsolete  equipment  used  for  other 
systems  to  which  AFIRMS  is  interfaced;  and, 

(b)  Moves  of  AFIRMS  to  other  equipment  to  make  way  for  other  new 
systems  or  to  take  advantage  of  new  equipment  capabilities. 

(6)  Over  interfaces  with  other  systems.  AFIRMS  is  impacted  by: 

(a)  Variations  between  systems  at  different  installations. 

(b)  Modification  of  source  systems  in  the  future. 

(c)  Budget  constraints  and  practicality  of  using  already  produced 
hardware  (e.g.,  Local  Area  Networks  (LANs)  to  accomplish  its 

mission).  .  , 

tfir 

(7)  Over  changes  in  requirements  to  readiness  assessments  and  reporting 
procedures. 

(8)  Over  means  of  displaying  data,  i.e.,  pie  charts,  viewgraphs,  line  graphs, 
etc. 

b.  To  achieve  these  types  of  flexibility,  AFIRMS  provides  for: 

( 1)  Analysis  of  user  requirements  over  all  MAJCOMs. 

(2)  Data  organization  that  stresses  similarities  among  site  types. 

(3)  Use  of  portable  languages. 

(4)  Modular  structuring  of  programs. 

(5)  Well  controlled  interface  gateways  between  external  systems,  database 
managers,  etc. 


4.4. 1  Inputs  and  Outputs.  The  products  by  which  the  data  are  entered  into  the  system  as 
well  as  the  products  by  which  the  data  are  provided  to  the  user  are  identified  in  the 
AFIRMS  Product  Descriptions.  A  detailed  description  of  the  data  used  in  the  AFIRMS 
system  data  is  provided  by  the  AFIRMS  Data  Requirements  Document. 

AFIRMS  data  can  be  viewed  as  consisting  of  four  categories,  each  consisting  of 
several  "kinds  of  things"  of  classes  of  entities.  For  each  of  the  entity  classes,  in  turn, 
several  kinds  of  data  (or  appearance  classes)  are  defined.  It  is  important  to  note  that  this 
is  a  logical,  abstract  view  of  the  data.  The  term  "appearance  class"  is  roughly  equivalent 
to  the  more  commonly  used  "data  element."  The  categories  and  their  major  entity  classes 
follow: 

a.  Standards  for  types  of  things  and  for  the  relationship  among  them.  Entity 

classes  include: 

(1)  Resource  Type.  (A  list  of  the  kinds  of  resources  AFIRMS  considers.) 

(2)  Task  Type.  (Kinds  of  tasks  referred  to  in  taskings  or  used  for  support  of 
those  primary  task  types.) 

(3)  Skill  Type.  (Kinds  of  skills  used.) 

(4)  Need  for  Resource  Type  by  Task  Type.  (What  does  it  take  to  do  the  job?) 

(5)  Resource  Sum  or  Assembly.  (What  resource  types  are  components  of 
other  resource  types?) 

b.  Orders  and  their  resource  needs.  Entity  classes  include: 

(1)  Order  Header.  (The  elements  common  to  all  copies  of  the  order.) 

(2)  AF  Unit's  Piece  of  Order.  (That  order  gives  what  tasks  to  my  unit?) 

(3)  Task.  (All  the  tasks  due  to  an  order,  both  primary  and  support  tasks.) 

(4)  Missions.  (The  tasks  which  are,  in  fact,  missions) 

(5)  Role  of  Resource  Type  on  Task.  (How  much  of  what  resources  are  needed 
to  accomplish  this  task;  A. 4  may  be  used  to  calculate  this) 


c.  Units,  Bases,  Resources.  Entity  classes  include: 

( 1)  Air  Force  Unit  (A  squadron,  wing,  MAJCOM,  or  the  total  Air  Force.) 

(2)  Base. 

(3)  Unit’s  supply  of  resource.  (How  much  of  what  item  does  each  unit  have?) 

(4)  Aircraft.  (A  tally  of  individual  items  as  opposed  to  the  total  count 
provided  by  C.3.) 

d.  Planning  to  Carry  Out  a  Task.  Entity  classes  include: 

(1)  Sortie.  (The  response  to  the  tasking  of  a  mission.) 

(2)  Allocation  to  Task.  (How  much  of  each  resource  is  committed  to  the 
sorties  planned?  Note  that  this  quantity  must  not  exceed  the  amounts 
available.) 

These  categories,  for  which  only  partial  lists  of  entity  classes  are  provided,  reflect 
the  basic  AFIRMS  approach.  Category  B,  orders,  are  compared  to  Category  A,  resources, 
to  develop  Category  D,  the  capability  to  carry  out  the  tasking.  Category  A,  standards, 
are  used  at  various  stages  in  the  process. 

4.4.2  Database.  The  AFIRMS  Database  Specification  discusses  the  factors  considered  in 
designing  the  AFIRMS  databases  and  identifies  the  data  to  be  stored  at  each  of  the  levels 
and  functional  areas  within  levels.  Significant  issues  include:  security,  the  need  to 
provide  easy  ad  hoc  queries  to  users,  handling  of  what-if  databases,  speed,  data 
consistency,  integrity,  restoration  <jf  historic  data,  and  deployability.  A  central  and 
critical  issue  is  the  number  of  copies  of  the  database  which  are  maintained.  The  LPP 
experience  suggested  a  limit  of  six  copies  of  the  database  is  sufficient  to  handle  exercise, 
peace,  crisis,  historic  and  what-if  requirements. 

An  overall  AFIRMS  database  architecture  has  been  developed.  Development  of  the 
specific  design  depends  on  the  final  selection  of  hardware  and  system  software  for  the 
MAJCOM  AFIRMS  system  components.  These  selections,  in  turn,  depend  on  specific 
detailed  functional  requirements  definition  efforts  accomplished  in  the  Analysis  Phases  of 
the  initial  segment  implementations. 


4.4.2. 1  Number  of  Copies  of  Each  Database.  AFIRMS  requires  support  for  databases  to 
serve  three  functional  purposes:  day-to-day  peacetime  operation;  support  of  crisis 
operations  and  contingency  exercises;  and  support  of  what-if  queries  (e.g.,  POM/Budget). 
For  each  of  these,  in  addition  to  local  backup  procedures,  there  is  a  need  for  off-site 
replication  and  storage  of  the  database  in  whole  or  in  part.  The  following  comments 
ignore  the  need  for  off-site  replication: 

a.  Each  site,  (wing,  MAJCOM,  HQ  USAF),  will  have  a  single  copy  of  its  own 
day-to-day  operational  databases. 

b.  Each  site  may  need  one  or  more  exercise  databases  to  support  exercises 
initiated  at  its  own  site  or  at  other  levels. 

c.  Each  site  may  need  one  or  more  what-if  database(s). 

Databases  containing  other  than  real  data  supporting  day-to-day  operations  are 
classified  as  a  what-if  or  historic  database.  This  includes  exercise,  ad  hoc,  what-if,  and 
historical  data.  Exercise  data  may  support  simulation  of  a  real  crisis.  Ad  hoc  what-if 
data  supports  hypothetical  situations  (e.g.,  POM/Budget),  and  historical  data  supports  the 
need  to  review  any  of  the  other  types  of  data  for  trend  analysis  purposes.  A  total  of  five 
on-line  copies  of  these  databases  are  allowed  on-line  at  any  time  in  any  combination  for 
each  AFIRMS  functional  user. 


Each  site  has  a  centrally  located  database.  All  functional  areas  of  that  site  have 
databases  locally  resident  on  their  hardware  which  is  a  subset  of  the  central  database.  It 
is  anticipated  that  all  functional  areas  may  not  need  the  capability  to  view  historical  or 
what-if  data  in  five  copies.  However,  for  planning  purposes,  this  functionality  is 
uniformly  distributed  over  all  functional  users.  Specific  data  requirements  for  what-if 
and  historical  usage  will  vary  by  MAJCOM  and  so  must  be  identified  in  the  Analysis 
Phases  of  the  initial  MAJCOM  implementations. 
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items  set  forth  in  the  sample  table  below.  (Entries  are  intentionally  irrelevant.) 


y 


w 


|  Item 

Length 

(bytes) 

Quantity 

Total 

Space  (K  bytes) 

Airman 

180 

250 

45 

Aircraft 

92 

80 

_7 

1  Total  Storage  Space 

52 

Such  tables  using  all  items  and  real  numbers  are  provided  in  the  Database 
Specifications.  Total  database  size  requirements  are  Riven  by  functional  user  in  these 
specifications  as  well  as  for  the  central  database. 

Each  replication  of  a  site's  database  increases  the  site's  database  size.  Thus,  if  the 
basic  size  of  one  database  were  52  K  bytes  and  6  copies  are  required  to  satisfy  peacetime 
operations  and  simultaneously  supporting  a  mix  of  exercises  and  what-if  questions,  the 
actual  database  size  would  be  312  Kbytes  (6  x  52K). 
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SECTION  5.  ENVIRONMENT 


5.1  Equipment  Environment.  Equipment  is  provided  to  each  AFIRMS  site  on  an  "as 
needed"  basis.  AFIRMS  uses  existing  facilities  and  equipments  wherever  possible.  Each 
site  in  the  operational  AFIRMS  has  the  potential  for  having  a  different  configuration, 
dependent  upon  site-unique  requirements  and  existing  computing  assets.  However,  at  a 
minimum,  each  AFIRMS  site  contains  the  equipment  required  for  the  CNM.  The  CNM 
contains  the  AFIRMS  database  for  that  site  as  well  as  the  communications  support  for 
site-to-site  communications.  The  System  and  Subsystem  Specifications  developed  with 
the  Evolutionary  Implementation  Plan,  address  detailed  equipment  requirements.  In 
general,  however,  two  basic  hardware  options  are  available  to  AFIRMS: 


a.  Implement  AFIRMS  on  existing  hardware  with  additional  AFIRMS  equipment 
added  as  needed,  e.g.: 

(1)  WWMCCS  Honeywell  H-6Q0Q  now  installed  at  all  AFIRMS  targeted 
MAJCOMs/HQ  USAF. 

(2)  Phase  IV  Sperry  1 100/60  Computerts)  to  be  installed  at  all  bases. 

This  approach  appears  to  be  a  cost-saving  idea.  At  the  MA3COM/HQ  USAF 
echelons,  the  WWMCCS  computers  could  be  a  viable  choice.  They  offer  the 
security  protection*  and  standardized  modular  hardware;  however,  they  are 
already  heavily  loaded. 

At  the  wing  level,  the  Phase  IV  system  does  not  provide  a  viable  choice  for 
AFIRMS  due  to  security  issues  -  the  Phase  IV  system  handles  unclassified  data 
only. 

Note  that  this  approach  will  most  certainly  require  that  existing  equipment  be 
supplemented  with  AFIRMS  hardware  -  database  machines,  color  and 
black/white  terminals,  etc.  This  opens  a  whole  new  area  of  hardware/software 
interfaces,  user  priorities,  and  so  forth. 

b.  Implement  AFIRMS  on  dedicated  hardware.  This  second  approach  implements 
AFIRMS  sites  on  dedicated  hardware. 


♦All  users,  however,  must  have  Top  Secret  security  clearances. 
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5.1.1  General  Equipment.  The  AFIRMS  system  and  subsystem  architecture  is  designed  to 
be  easily  reconfigured  for  different  sites  as  the  requirements  for  each  site  becomes 
known,  and  as  they  change.  The  architecture  consists  of  at  least  two  classes  of  computer 
equipment:  central  node  equipment  and  functional  area  equipment. 


5. 1.1.1  Centred  Node  Equipment.  Each  AFIRMS  site  consists  of  a  Central  Node 


containing  the  central  mass  storage  devices  for  that  site,  a  network  controller,  and  one  or 
more  Central  Node  modules.  The  mass  storage  devices  consist  of  devices  to  hold  an 
on-line  central  database  and  load/store  data  and  software.  These  devices  have  data  paths 
to  all  of  the  Central  Node  resident  modules.  A  Central  Node  module  has  a  data  path  to 
one  or  more  other  Central  Node  module.  The  Central  Node  module's  primary  use  is  to 
synchronize  the  site's  central  database  with  other  databases.  The  other  databases  consist 
of  those  at  other  sites  and  those  at  the  other  functional  area  workstations.  For  a  more 
detailed  description  of  Central  Node  equipment  components,  refer  to  the  AFIRMS  System 
Specification. 


5. 1.1.2  Functional  Area  Equipment.  Functional  area  workstations  provide  the  human 


interface  to  AFIRMS.  Each  functional  area  which  needs  to  enter  or  examine  AFIRMS 
data  has  a  functional  area  workstation  to  communicate  with  the  Central  Node.  These 
functional  area  workstations  are  microcomputers  with  a  hard  disk  capable  of  running  a 
local  database  and  data  manipulation  software  for  the  users  at  the  functional  area.  This 
workstation  may  support  one  or  more  terminals  with  complex  color  graphs  or  simple 
monochrome  (standard  black  and  white)  displays. 


Functional  area  workstations  with  color  graphics  terminals  are  provided  to  support 
the  decision-makers  and  are  expected  to  be  located  at  the  major  decision  points  around 
the  AFIRMS  site.  Functional  area  workstations  with  monochrome  CRT  terminals  will 
function  primarily  as  input  and  output  devices  located  to  support  the  middle  managers  in 
day-to-day  system  operations.  The  CRT  terminals  will  not  have  a  graphics  capability,  but 
can  present  data  in  a  tabular  format.  See  the  Subsystem  Specifications  for  details  on  the 
terminal  distributions. 


3.1.2  Wing  Equipment.  Wing  sites  architectures  are  identical.  The  specific  design  may 
vary.  For  example,  the  number  of  input  and  output  devices  may  vary  as  well  as  the 
number  of  disks  required  for  database  storage.  The  wing  AFIRMS  site  has  an  equipment 
core  that  typically  serves  the  wing  headquarters  and  command  post.  In  addition,  each 
squadron  affiliated  with  the  wing  has  additional  functional  area  workstations  that  "plug 
into"  the  core  wing  hardware. 

r 

Functional  area  workstations  with  color  graphics  terminals  are  expected  to  be 
located  at  the  major  decision  points  around  the  wing  such  as  the  WOC,  the  maintenance 
Job  Control  Center,  the  Munitions  and  Fuels  Control  Centers,  wing  headquarters,  and  the 
flying  squadron(s)  operations  area.  Some  of  the  locations  for  the  monochrome  CRT 
include  the  WOC,  Aircraft  Maintenance  Units  (AMUs),  fuels  branch,  and  base  supply. 


3.1.3  MA3COM/HQ  USAF  Equipment.  Hardware  configurations  for  these  AF1RMS  site 
types  are  expected  to  be  architecturally  identical. 

Analogous  to  the  wing  level,  color  graphics  workstations  are  provided  for  at  the 
MA3COM  and  HQ  USAF  sites  to  support  decision-makers,  and  are  located  at  each  site's 
major  decision  points.  Similarly,  monochrome  CRT  workstations  function  primarily  as 
input  and  output  devices  and  are  located  to  support  MAJCOM/HQ  USAF  middle 
managers.  For  a  detailed  breakdown  of  CRT  terminal  locations,  refer  to  the  appropriate 
AFIRMS  Subsystem  Specification. 

3.2  Support  Software  Environment.  The  AFIRMS  subsystem  applications  software 
interfaces  with  the  following  support  software: 

a.  Operating  System 

b.  System  Utility  Routines 

c.  Communications  Software 

d.  Database  Management  System  (DBMS) 

e.  Display/Graphics  Software 

f.  Restart/Recovery  Software 

g.  Transaction  Control  Software 


For  more  detailed  AFIRMS  subsystem  support  software  requirements,  refer  to  the 
corresponding  AFIRMS  Subsystem  Specification. 
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5.3  Interfaces.  AFIRMS  is  a  set  of  subsystem  sites  requiring  data  transfer 
between  and  within  the  various  sites.  In  addition,  an  AFIRMS  interface  with 
existing  and  future  automated  systems  is  required.  The  AFIRMS  philosophy  for 
data  collection  is  to  collect  no  more  than  is  needed  and  not  to  collect  data 
if  it  is  already  collected  in  automated  systems.  If  it  is  in  other  systems 
(and  meets  AFIRMS  criteria  for  accuracy  and  timeliness),  then  AFIRMS  where 
feasible,  interfaces  with  those  systems  to  obtain  the  data. 


5.3.1  Systems  Interface  Candidates.  AFIRMS  interfaces  with  MAJCOM  unique, 
Air  Force  standard,  and  DoD  systems  in  order  to  collect  the  resource 
summary/status  data  necessary,  and  to  produce  the  AFIRMS  readiness  tools. 
These  interfaces  are  also  required  to  communicate  between  and  within  the  Air 
Force  organizational  structure  of  AFIRMS.  Interfaces  with  communications 
systems,  logistics  management  systems  of  the  Air  Force  Logistics  Command 
(AFLC),  personnel  management  systems  and  command/control  (tasking)  systems, 
provide  necessary  AFIRMS  data  while  minimizing  data  system  redundancies. 
Systems  with  which  AFIRMS  is  likely  to  interface/integrate,  include: 

SYSTEM  INTERFACE  AREA 


Airlift  Deployment  Analysis  System  (ADANS)  Replacement  for  FLOGEN 

III. 

Air  Force  Information  System  Architecture  Efforts  AFIRMS  architecture  and 

environment 


Air  Force  Operations  Resource  Management 
(AFORMS) 

Airlift  Implementation  and  Monitoring 
System  (AIMS) 


System  Aircrew  status 

MAC  aircraft  schedule 
and  movement  information 


Base  Level  Data  Automation  Program  (Phase  IV) 


Data  integration 


Combat  Ammunition  System  (CAS) 


Combat  ammunitions 
inventory  and  status 


Combat  Fuels  Management  System  (CFMS) 


Combat  fuels  inventory 
and  status 
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SYSTEM 


INTERFACE  AREA 


Combat  Supplies  Management  System  (CSMS) 

Combat  Supply  System  (CSS) 

Contingency  Operations/Mobility  Planning  and 
Execution  System  (COMPES) 

Core  Automated  Maintenance  System  (CAMS) 

Dyna-METRIC/mini  Dyna-METRIC  Model 

Electronic  Information  Command  and  Control 
System  for  Operational  Readiness  of  the 
Luftwaffe  (EIFEL) 

European  Distribution  System  (EDS) 

Force  Generator,  Version  3  (FLOGEN  III) 

Flow  Management  Information  System  (FMIS) 

Information  Processing  System  (IPS) 

Local  Area  Network.  (LAN)  Efforts 

Logistics  Capability  Measurement  System  (LCMS) 

Military  Air  Integrated  Reporting  System  (MAIRS) 

Standard  Air  Force  Small  Computer  Requirements 
Contract  Efforts 

Standard  Base  Supply  System  (SBSS) 

Technique  for  Assessing  Comparative  Force 
Modernization  (TASCFORM) 

Theatre  Airlift  Management  System  (TAMS) 

Vehicle  Integrated  Management  System  (VIMS) 


Spares  status 

Standard  Base  Supply 
System  (SBSS)  data 

Tasking  and  force 
structure 

Spares,  maintenance 
support  personnel  status 

Spares  capability 

Tasking  and  force 
structure  (in  USAFE) 


Spares  status  (in  USAFE) 

MAC  automated  mission 
flow  generator 

SAC  force  and  resource 
status  data 

MAC  command  and  control 
data 

Communications  (local) 
Spares  status 
MAC  mission  movement  data 
Hardware 


Spares,  fuels,  personnel 
status 

Force  modernization 


In-theatre  mission  flow 
and  tracking  data  for 
deployed  MAC  aircraft 

Base  Level  vehicle 
maintenance  performance 
data 


CDRL  0023 


5-4.1/CHG  1 


SYSTEM 


INTEGRATED  AREA 


Weapon  System  Management  Information  System 
(WSMIS) 

WVMCCS  Information  System  (VIS/AFVIS) 

A  number  of  programs  are  working  in  the  direction  of  data  automation 
standardization.  In  large  measure,  the  progress  of  AFIRMS  interface  with 
other  systems  will  hinge  on  the  pace  of  the  Defense  Data  Network  (DDN), 
Automated  Message  Processing  Exchange  (AMPE),  LANs,  and  SCOPE  EXCHANGE/DIAL, 
PHASE  IV  base-level  automation  and  other  programs  associated  with  the  USAF 
Information  System  Architecture.  These  efforts  will  form  the  ideal  AFIRMS 
interface  mechanism  as  other  systems  evolve  to  conform  to  the  architecture. 

5.4  Summary  of  Impacts.  This  section  addresses  the  expected  ADP  '■ 
organizational,  operational,  and  developmental  impacts  introduced  by  AFIRMS. 


Spares  capability 


Communications 

(long-line) 
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5.4. 1  ADP  Organizational  Impacts.  General  observations  are  made  at  this  time  based 
upon  impacts  that  often  occur  with  any  new  ADP  system. 


a.  Additional  ADP  support  personnel  are  needed  at  each  wing,  HQ  MAJCOM,  and 
HQ  USAF  to  maintain  the  system  and/or  provide  program  maintenance  support 
and  other  programming  support  as  the  system  evolves. 

b.  DSDO  will  support  the  operational  system  as  is  now  done  for  other  Air  Force 
ADP  systems. 


c.  An  AFIRMS  Users  Group  is  established  to  make  recommendations  regarding 
product  enhancements  and  identify  new  and  improved  ways  to  use  products  in 
their  daily  jobs.  The  group  meets  to  exchange  viewpoints  and  publishes 
proceedings  within  the  Configuration  Management  Systems. 

d.  A  "Super  User"  or  resident  expert  within  each  MAJCOM  (perhaps  the  MAJCOM 
OPR  for  the  AFIRMS  Users  Group)  who  can  assist  wing  and  MAJCOM  level 
users  with  their  questions/problems  could  also  be  beneficial  to  ensuring  good 
use  of  the  AFIRMS  system. 


5.4.2  ADP  Operational  Impacts.  Impacts  on  operational  procedures  of  the  data 
processing  centeKs)  when  AFIRMS  is  implemented  depends  upon  the  nature  of  the  ADP 
installation.  It  is  expected  that  when  an  Air  Force  ADP  system  interfaces  with  AFIRMS, 
that  interface  will  increase/complicate  the  system/program  maintenance  workload  for 
each  system  and/or  program  interfacing  with  AFIRMS.  The  specific  impacts  generated  by 
specific  implementations  are  identified,  reviewed,  and  accommodated  in  the  Analysis 
Phase  of  the  implementation  block. 


5.4.3  ADP  Developmental  Impacts.  Air  Force  personnel  and  ADP  development  resources 
needed  to  develop  and  test  AFIRMS  are  discussed  in  the  AFIRMS  Economic  Analysis. 
Contractor  support  is  expected  to  predominate  in  the  initial  analysis,  design  and 
programming  effort  for  the  first  block  of  each  MAJCOM  segment.  Additionally,  Air 
Force  ADP  support  is  required  for  the  following  efforts  during  the  first  block  of  each 
segment: 


Participate  in  integration  testing  of  the  contractor  sys+  :m  installation,  as  a 
transition  to  operation  and  maintenance  of  the  system. 

Assist  Air  Force  users  in  initializing  the  database  at  each  AFIRMS  site  after 
the  systems  are  installed. 


c. 


Assist  in  defining  interface  methods  for  automated  information  systems  that 
are  identified  as  interface  candidates.  Develop  any  software  required  of  Air 
Force  information  systems  with  which  AFIRMS  is  to  interface. 


5.5  Failure  Contingencies.  This  section  deals  with  restart  of  an  AFIRMS  site  after  it  has 
been  reintroduced  into  service  either  from  a  nonoperating  or  a  partially  operating  state. 

It  does  not  address  the  issues  of  fall  back  and  backup  as  discussed  in  Section  3.5  of  this 
document. 

The  decisions  as  to  how  an  AFIRMS  site  should  be  brought  back  on-line  are  complex, 
closely  related  to  how  the  system  is  designed,  and  closely  related  to  the  kind  of  failure. 

At  one  end  of  the  spectrum  of  complexity  is  the  loss  of  a  dumb  input/output 
terminal.  In  this  case,  if  the  problem  is  communications  or  the  terminal  itself,  the 
terminal  is  simply  unavailable  for  input  or  output  and  users  must  time  share  with  other 
nearby  terminals,  use  a  temporary  replacement  terminal,  or  do  without  a  terminal  until 
the  fault  is  corrected.  If  the  lost  terminal  were  a  smart  device,  the  range  of  possibilities 
increases,  possibly  to  the  point  of  entering  database  update  transactions  (this  latter 
capability  is  a  function  of  the  system  design).  At  the  complex  end  of  the  spectrum  is  the 
case  in  which  the  portion  of  a  site  that  controls  the  database  has  been  unavailable  for  a 
period  of  time.  When  it  does  become  available,  other  AFIRMS  sites,  smart  terminals 
within  the  site,  and  other  system  interfaces,  may  have  database  updates  or  requests 
pending.  Furthermore,  a  journal  file  of  historical  transactions  (since  the  last  database 
backup)  must  be  used  to  bring  the  database  current  to  the  time  when  the  system  failed  if 
a  disk  failure  (head  crash)  occurred. 

The  specific  failure  modes  of  each  AFIRMS  site  type  and  the  sequence  of  steps  for 
restart  depend  upon  the  specific  failure,  and  the  design  of  the  AFIRMS  site.  The  AFIRMS 
site  designs  assure  that  failure  recovery  is  systematic  and  deterministic.  Flow  diagrams 
are  developed  to  identify  the  sequence  of  actions  that  must  be  initiated  to  bring  the 
system  to  a  full  on-line  state  from  each  failure  condition. 

In  any  event,  the  Analysis  Phase  for  block  one  of  each  segment  will  determine  the 
failure  contingencies,  degraded  mode  capabilities  required,  and  all  fallback  modes  of 
operation. 
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5.6  Security.  The  security  environment  for  the  operational  AFIRMS  varies  at 
the  wing,  MAJCOM,  and  HQ  USAF  sites.  AFIRMS  wing  sites  generally  operate  in  a 
controlled  security  mode  with  a  mixture  of  classified  and  unclassified 
terminal  users.  HQ  USAF,  MAJCOM,  and  SAC  wing  sites  operate  in  the  system 
High  Security  mode.  Each  AFIRMS  site,  and  collectively  the  AFIRMS  network, 
will  be  accredited  for  processing  classified  data  in  accordance  with  AFR 
205-16  and  other  DoD  and  Air  Force  security  directives.  Refer  to  Section  3.6 
for  additional  information. 


5.7  Assumptions  and  Constraints.  The  following  assumptions  are  made  in 
regards  to  the  AFIRMS  operational  system  architecture: 


a.  Technical  risk  factors  inherent  in  the  architecture  must  be  low  to 
medium. 

b.  Technology  assumed  in  architecture  must  be  currently  applied 
technology.  (Near  state-of-the-art  but  no  extensive  R&D.) 

c.  The  useful  life  inherent  in  the  architecture  must  be  a  minimum  of  ten 
years. 

d.  Peacetime  reliability/availability  must  be  high.  Wartime 
survivability  requirements  were  considered,  but  deemed  too  costly. 
AFIRMS  will  operate  as  long  as  possible  in  wartime,  but  it  is  not  a 
wartime  survivable  system. 

e.  Deployed  units  must  have  the  capability  (as  a  minimum)  to  report  to 
the  AFIRMS  system. 

f.  Peacetime  includes  crisis  situations. 

g.  The  system  is  designed  in  such  a  manner  as  to  minimize  the  difficulty 
in  interfacing  to  other  systems  in  the  future. 

h.  Data  currency  is  defined  as  the  maximum  amount  of  time  allowable 
before  data  resident  at  multiple  locations  are  updated  after  the  data 
at  one  location  is  changed. 

(1)  Local  site:  data  currency  must  be  achieved  within  3  minutes  for 
mission  related  data.  This  must  occur  90 X  of  the  time  with  the 
system  operating  in  a  normal  mode.  Data  currency  must  be 
achieved  within  1  hour  for  non-mission  related  data.  This  must 
occur  90%  of  the  time  with  the  system  operating  in  a  normal  mode 
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.  (2)  Intersite:  data  currency  must  be  achieved  within  6  hours  for 

data  shared  between  a  wing  site  and  a  MAJCOM  site.  This  must 
occur  90 X  of  the  time  with  the  system  operating  in  a  normal 
mode.  Data  currency  must  be  achieved  within  12  hours  for  data 
shared  between  a  MAJCOM  site  and  the  HQ  USAF  site.  This  must 
,  occur  90%  of  the  time  with  the  system  operating  in  a  normal  mode 
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Data  age  is  the  time  allowable  between  prescribed  data  updates  between  sites 
regardless  of  intermediate  changes  in  the  data. 

(1)  A  6  hour  update  cycle  is  required  for  data  between  a  wing  site  and  a 
MA3COM  site.  A  12  hour  update  cycle  is  required  for  data  between  a 
MAJCOM  site  and  the  HQ  USAF  site. 

Response  times  vary  depending  on  the  complexity  of  the  queries  and  the  types 
of  processes  involved  with  the  query.  For  planning  purposes,  the  following 
response  times  are  used  for  a  query  limited  to  the  local  site.  (Automatic 
system  intersite  queries  are  not  permitted.) 

(1)  Complex  Query  -  11  seconds  or  greater. 

(2)  Medium  Query  -  4  seconds  to  10  seconds. 

(3)  Simple  Query  -  1  seconds  to  3  seconds. 

The  definition  of  the  terms  complex,  medium,  and  simple  vary  by  functional 
user,  or  at  least  by  MAJCOM.  Specific  definition  will  be  determined  in  the 
Analysis  Phase  of  each  segment  implementation  block. 

The  operational  AFIRMS  operates  in  a  secure  controlled  mode  across  all  sites. 

A  site  system  must  be  easily  expandable  without  major  modification  to  the 
software  and  without  requiring  replacement  of  all  or  most  of  the  existing 
hardware. 


SECTION  6.  COST  FACTORS 


6. 1  General  Process.  This  section  describes  the  breakdown  of  costs  and  benefits  used  to 
analyze  the  economic  life  of  alternatives  for  building  the  operational  AFIRMS.  The 
estimated  life-cycle  cost  of  the  recommended  alternative  is  discussed  briefly  and 
itemized  in  terms  of  the  generic  cost  and  benefit  factors.  Costs  are  stated  in  current 
dollars  (the  total  of  the  expenses  in  each  of  the  years).  The  total  cost  is  then  restated  in 
terms  of  present  value  (the  amount  which,  if  invested  today,  would  provide  the  needed 
dollars  over  the  years  of  the  program  assuming  that  both  capital  and  interest  were  spent). 
The  costing  of  each  alternative  is  based  on  an  evolutionary  implementation  approach  and 
on  MAJCOM  differences  in  mission,  deployments,  and  existing  automation. 

The  recommended  alternative,  called  "Hybrid  Architecture,"  provides  hardware  and 
support  to  wings  without  significant  unit  automation.  This  alternative  recommends 
installation  of  a  central  computer  and  workstations  in  such  wings,  but  would  use  the 
existing  automation  where  available.  This  alternative  also  provides  deployable  equipment 
when  required  and  integrates  AFIRMS  with  other  Air  Force  standard  and  MAJCOM  unique 
systems.  The  life-cycle  cost  of  the  recommended  "Hybrid  Architecture"  alternative  is 
$240  million  in  current  dollars.  This  cost  includes  estimated  cost  of  $ 1 30  million  for 
implementing  AFIRMS  in  Air  Force  Reserve  and  Air  National  Guard  units. 


6.2  Explanation  of  Cost  Factors  and  Benefits.  Cost  factors  are  divided  into  recurring  and 
non-recurring  costs.  All  recurring  costs  are  classified  as  Operations  and  Maintenance 
(O&M).  The  0<5cM  costs  are  subdivided  into  expenses  for  personnel,  hardware,  software, 
supplies,  and  utilities.  The  non-recurring  costs  consist  of  development,  acquisition,  and 
installation. 


Major  benefits  are  divided  into  utility,  manageability,  and  timely  implementation. 
This  division  reflects  the  objectives  against  which  performance  in  the  category  is 
measured.  Utility  applies  to  the  information  output  and  system  utility.  Manageability  is 
a  combination  of  low  technical  and  management  risk.  Timely  implementation  emphasizes 
the  importance  of  obtaining  program  results  in  the  field  as  soon  as  possible,  even  if  the 
results  are  only  an  initial  improvement.  (Refer  to  the  Economic  Analysis  for  a  complete 
description  of  each  factor.) 
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6.3  Cost  Summary  of  the  Recommended  Alternative.  Analysis,  design,  and  programming 
costs  dominate  the  costing  analysis  but  are  less  than  45%  of  the  total  undiscounted  system 
cost.  Hardware  and  software  maintenance  costs  are  substantial  because  of  the  large 
equipment  requirement.  Additionally,  deployable  equipment  has  a  higher  rate  of 
maintenance  than  non-depioyable. 


nVs 


The  figures  below  summarize  the  estimated  costs  of  the  recommended  alternative. 
The  figures  are  provided  for  budgetary  evaluation.  A  full  discussion  of  the  costs  appears 
in  the  AFIRMS  Economic  Analysis. 


LIFE-CYCLE  COSTS 


Procurement 

$43,018,297 

O&M/Analysis,  Design  6c  Programming 

57,133,059 

O  6c  M  /  In  st  a  1  lat  ion 

13,228,659 

06cM/Hardware  6c  Software  Maintenance 

54,488,414 

06cM/Supplies 

3,024,446 

06cM/Communications  Links 

4,323,226 

Air  Force  Manpower 

Officer  (10) 

2,993,839 

Enlisted  (362) 

62,372,628 

Total  Current  Dollar  Cost 

240,580,109 

Total  Present  Value  Cost 

141,297,626 

til 


*  The  Total  Present  Value  is  based  on  the  10%  annual  discount  factors  given  in  AFP  178-8. 
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SECTION  7.  SYSTEM  DEVELOPMENT  PLAN 
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The  material  in  this  section  is  repeated  in,  and  expanded  on,  by  the  AFIRMS 
Evolutionary  Implementation  Plan. 


7.1  Contact  Point.  The  point  of  contact  for  the  evolutionary  implementation 
of  AFIRMS  is  the  Air  Force  Directorate  of  Operations.  The  AFIRMS  OPR  is 
designated  within  the  Directorate  of  Operations.  The  AFIRMS  Management  Plan 
contains  a  statement  of  the  OPR  responsibilities  as  well  as  those  of  the 
Program  Management  Office. 


D-* 


7.2  Implementation  Elements.  The  AFIRMS  EIP  is  composed  of  segments,  blocks, 
and  phases.  Each  MAJCOM  is  a  segment  of  the  EIP,  as  is  the  HQ  USAF.  Each 
segment  is  composed  of  a  number  of  blocks.  A  block  is  a  specified  set  or 
subset  of  functional  requirements  to  be  implemented.  These  requirements  are 
normally  represented  by  a  specific  set  of  AFIRMS  applications  products 
(screens  and  processes),  communications  capabilities,  and  interface 
requirements.  Each  block  is  composed  of  five  phases.  The  completion  of  the 
five  phases  implements  the  functional  requirements  identified  for  that  block. 
The  phases  of  a  block  contain  the  task  detailing  necessary  for  the 
analysis/requirements  definition,  the  development,  the  installation,  the 
operation,  and  the  integration/management  of  the  functional  block 
capabilities.  Figure  7-1  shows  the  relationship  between  the  segments,  blocks, 
phases,  and  time.  This  figure  shows  that  the  EIP  is  composed  of  segments 
(Segment  H  =  HQ  USAF  and  Segment  U  =  USAFE)  which  have  functional  capabilities 
implemented  as  sequential  blocks  over  time. 

Operational  AFIRMS  is  designed  to  be  used  on  a  day-to-day  basis.  The 
AFIRMS  set  of  readiness  and  capability  assessment  tools  available  to  each 
functional  user  are  tailored  to  the  work  requirements  and  status  information 
needs  of  that  user.  The  evolutionary  aspect  of  AFIRMS  implementation  has  two 
meanings.  Both  meanings  relate  to  time-phased  sequences  of  activities. 
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First,  the  implementation  of  the  initial  blocks  of  AFIRMS  functional 
capability  has  a  sequential  timetable  over  the  HQ  USAF  and  the  MAJCOMs.  The 
initial  block  within  each  segment  of  the  evolutionary  implementation  provides 
a  core  capability  for  the  HQ  USAF,  MAJCOM  headquarters  and  operating  units  of 
each  MAJCOM.  The  core  capability  may  be  different  for  Block  1  of  each  EIP 
segment  since  additional  capabilities  or  enhanced  capabilities  will  become 
available  over  time.  The 
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SEGMENT  U 
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MAJCOMs 


BLOCK  HI - ► 

BLOCK  H2 - - ► 

BLOCK  U1 - ► 

BLOCK  U2 - ► 

I 

PHASE  U2A - 

PHASE  U2D  - 

PHASE  U2I  - 

PHASE  1120  - 

PHASE  U2M - 


Figure  7-1.  AFIRMS  EIP  Structure 


SEGMENT 

=  The  HQ  USAF  or  MAJCOM  "slice"  of  AFIRMS.  (HQ  USAF  and 

USAFE  are  the  first  two  segments.) 

^  BLOCK 

J 

=  A  module  of  AFIRMS  functional  capability.  (Block  1  functionality  = 

LPP  functional  capabilities.) 

PHASE 

=  A  group  of  tasks  required  to  accomplish  a  block.  (Analysis, 

Development,  Installation,  Operation,  Integration/Management.) 

core  capabilities  for  the  first  segment  implementations  are  those  of  the  LPP  as  modified 
to  reflect  the  lessons  learned  during  LPP  trials  and  tests.  Second,  the  implementation 
provides  for  an  upgrade  of  the  core  capabilities  in  subsequent  blocks.  These  subsequent 
blocks  provide  additional  functional  capabilities  beyond  the  core  functions,  accommodate 
changing  missions  or  environments,  and  take  advantage  of  improved  data  processing 
technology. 


7.3  Schedule.  In  order  to  reduce  the  total  implementation  time  required  for  AFIRMS, 
block  development  efforts  for  several  MAJCOM  segments  must  occur  in  parallel. 

The  general  schedule  for  implementation  is  shown  in  Figure  7-2.  This  schedule  shows 
the  sequencing  of  segments  and  of  the  blocks  within  each  segment. 
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SEGMENT /BLOCK  1985  1986  1987  1988  1989  1990  1991  1992  1993  1994 


HQ  USAF  1 
HQ  USAF  2 
HQ  USAF  3 

USAFE  1 

USAFE  2 

AFLC-HQ  1 
AFLC-LOCs  2 
AFLC-HQ  3 
AFLC-LOCs  4 

PACAF  1 

PACAF  2 

TAC  1 

TAC  2 

AAC  1 

AAC  2 

SAC  1 

SAC  2 

MAC  1 

MAC  2 

AFRES  1 

AFRES-TAC  2 
AFRES-SAC  3 
AFRES-MAC  4 

ANG  1 

ANG-TAC  2 
ANG-SAC  3 
ANG-MAC  4 


Figure  7-2.  AFIRMS  Master  Implementation  Schedule 

7.4  Segments  of  the  Evolutionary  Implementation  Plan.  A  segment  of  the  E1P  is  a  major 
command  "slice"  or  the  HQ  USAF  portion  of  AFIRMS.  Control  of  AFIRMS  implemented  is 
achieved  through  the  Major  Command  Segment  Plans.  The  following  tasks  provide  a 
framework  within  which  implementation  priorities  can  be  set  and  progress  monitored. 

a.  Development  and  accomplishment  of  the  AFIRMS  Program  Management  Plan. 

b.  Development  and  accomplishment  of  the  EIP  and  its  segment  plans. 
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c.  Preparation  and  Update  of  the  Data  Project  Plan. 

d.  Development  and  accomplishment  of  the  Configuration  Management  Program.  "Ja 

e.  Program  Objective  Memoranda  (POM)  and  budget  advocacy. 

f.  Implemenation  scheduling. 

g.  Supervision  of  the  system  developers  (whether  Air  Force  or  contractor). 

h.  Staff  supervision  of  worldwide  system  operation  and  main+enance. 

i.  Problem/action  reporting. 


7. 5  Blocks  of  the  Evolutionary  Implementation  Plan.  A  block  is  a  specific  set  of  AFIRMS 
functional  capabilities.  Blocks  are  defined  in  terms  of  statements  of  functional  need,  which 
are  based  upon  the  AFIRMS  Functional  Description.  Functional  needs  may  be 
readiness/sustainability  assessment  tools,  interfaces  with  other  MAJCOM/Air  Force/DoD 
systems,  or  enhancements  to  these  types  of  capabilities.  Blocks  are  defined  and  scheduled  in 
the  AFIRMS  Management  Plan  and  are  controlled  by  the  Configuration  Management  Program. 


Selection  of  functional  requirements  for  implementation  in  a  particular  block  in  a 
specific  MA3COM  segment  is  made  from  the  list  of  unsatisfied  requirements  for  that 
MA3COM.  This  list  of  unsatisfied  requirements  is  compiled  by  the  AFIRMS  HQ  USAF  Office 
of  Primary  Responsibility  (OPR)  and  the  Program  Management  Office  (PmO),  from 
problem/action  reports  received  from  the  MA3COM,  from  the  set  of  available  or  projected 
AFIRMS  products  as  they  are  developed  and  from  specific  statements  of  requirement  from 
MA3COM  representatives. 


7.6  Phases  of  Evolutionary  Implementation  Plan  Blocks.  A  phase  is  one  of  five  sets  of 
actions  necessary  to  achieve  the  functional  capabilities  of  a  block  in  the  AFIRMS  EIP. 


7.6.1  Analysis/Requirements  Definition  Phase.  The  Analysis/Requirements  Definition  Phase 
consists  of  those  steps  necessary  to  design  and  specify,  in  detail,  the  functional  needs 
programmed  for  a  block  in  the  AFIRMS  Management  Plan.  The  completion  of  this  phase 
results  in  system/subsystem  specifications,  database  specifications,  and  supporting  documents 
such  as  the  System  Development  Plan  and  the  Test/Verification/Validation  Plan. 
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7.6.2  Development  Phase.  The  Development  Phase  consists  of  those  steps 
necessary  to  create  the  products  that  accomplish  the  functional  needs 
programmed  for  a  block  in  the  AFIRMS  Management  Plan.  The  completion  of  the 
Development  Phase  results  in  creation,  and  stand-alone  testing,  of  the  program 
coding  necessary  to  accomplish  the  functional  requirements.  The  Development 
Phase  also  provides  the  Training  Plan,  Maintenance  Plan,  Installation  Plan, 
and  the  User/Operator  Documents. 


7.6.3  Installation  Phase.  The  Installation  Phase  consists  of  those  steps 
necessary  to  place  the  functional  cpapabilities  into  operation.  The 
completion  of  this  phase  results  in  the  modifying  facilities  (if  necessary), 
acquiring  and  placing  communications  lines  and  computer  hardware  into  service, 
installing  software,  and  conducting  training. 


I 

7.6.4  Operations  Phase.  The  Operations  Phase  consists  of  those  steps 
necessary  to  operate  and  maintain  the  operational  system.  System  maintenance 
(hardware  and  software)  is  of  primary  concern  during  this  phase.  The 
completion  of  the  Operations  Phase  is  established  by  the  completion  of  a  new 
implementation  block. 


7.6.5  Systems  Integration/Manageaent  Phase.  The  Systems  Integration/ 
Management  phase  consists  of  those  steps  necessary  to  monitor  and  guide  the 
block  installation  in  accordance  with  the  AFIRMS  Management  Plan  Annex  B, 
Evolutionary  Implementation  Plan.  Actions  in  this  phase  are  concurrent  with 
the  Analysis,  Development,  Installation  and  Operations  Phases.  Actions  in  the 
Systems  Integration/Management  Phase  result  in  control  of  the  block 
implementation,  preservation  of  system  integrity,  and  in  monitoring  of  the 
worldwide  AFIRMS  operations. 
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7.6.2  Development  Phase.  The  Development  Phase  consists  of  those  steps  necessary  to 
create  the  products  that  accomplish  the  functional  needs  programmed  for  a  block  in  the 
AFIRMS  Management  Plan.  The  completion  of  the  Development  Phase  results  in  creation, 
and  stand-alone  testing,  of  the  program  coding  necessary  to  accomplish  the  functional 
requirements.  The  Development  Phase  also  provides  the  Training  Plan,  Maintenance  Plan, 
Installation  Plan,  and  the  User/Operator  Documents. 


7.6.3  Installation  Phase.  The  Installation  Phase  consists  of  those  steps  necessary  to  place 
the  functional  cpapabilities  into  operation.  The  completion  of  this  phase  results  in  the 
modifying  facilities  (if  necessary),  acquiring  and  placing  communications  lines  and 
computer  hardware  into  service,  installing  software,  and  conducting  training. 


7.6.4  Operations  Phase.  The  Operations  Phase  consists  of  those  steps  necessary  to 
operate  and  maintain  the  operational  system.  System  maintenance  (hardware  and 
software)  is  of  primary  concern  during  this  phase.  The  completion  of  the  Operations 
Phase  is  established  by  the  completion  of  a  new  implementation  block. 


7.6.5  Systems  Integration/ Management  Phase.  The  Systems  Integration/Management 
phase  consists  of  those  steps  necessary  to  monitor  and  guide  the  block  installation  in 
iccordance  with  the  AFIRMS  Management  Plan.  Actions  in  this  phase  are  concurrent 
with  the  Analysis,  Development,  Installation  and  Operations  Phases.  Actions  in  the 
Systems  Integration/Management  Phase  result  in  control  of  the  block  implementation, 
preservation  of  system  integrity,  and  in  monitoring  of  the  worldwide  AFIRMS  operations. 
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APPENDIX  A.  THE  AFIRMS  METHODOLOGY  MODEL 


A.  1  Introduction.  This  appendix  presents  the  formal  version  of  the  Structured  Analysis 
and  Design  Technique  (SADT)  model  upon  which  the  information  in  Sections  3.2.2,  4.1.6, 
and  4.2.6  are  based.  A  general  explanation  of  SADT  models  is  provided  on  this  and  the 
following  pages. 

A.2  How  To  Read  An  SADT  Model  -  General  Discussion.  The  SADT  graphic  technique 
uses  a  series  of  diagrams  to  describe  a  system  with  each  level  of  diagrams  representing  a 
greater  level  of  detail. 

The  top  level  diagram  is  a  single  box  representing  a  major  activity.  That  box  is 
broken  down  into  another  diagram  containing  three  boxes  that  detail  the  major  activity 
into  sub-activities.  Likewise,  each  of  those  boxes  is,  in  turn,  broken  down  into  a  diagram 
containing  three  to  six  boxes  (see  Diagram  A-l).  The  detailing  continues  until  the  desired 
level  is  reached.  The  resultant  structure  is  summarized  in  outline  format  by  the  "nooe 
list"  on  page  A-3. 


Diagram  A-l.  SADT  Diagram  Breakdown 
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A-l 


Each  box  in  a  diagram  represents  a  specific  activity  and  is  named  with  a  verb  or  verb 
phrase.  Each  of  the  four  sides  of  the  box  represents  a  specific  type  of  data?  input  data 
enters  on  the  left  side;  control  data  enters  on  the  top;  output  data  exits  on  the  right  side; 
and,  devices  enter  from  the  bottom  (Diagram  A-2). 


INPUT 

DATA 


CONTROL 

DATA 


DEVICE 


OUTPUT 

DATA 


Diagram  A-2.  SADT  Activity  Box 


Input  data  is  data  which  is  to  be  transformed  by  the  activity.  Output  data  is  data 
transformed  by  the  activity  and  is  to  be  used  elsewhere.  Control  data  is  data  that  guides 
the  operations  of  an  activity.  The  devices  describe  the  equipment,  organizations,  or 
persons  which  perform  the  given  activity.  Device  arrows  are  often  omitted  or  oeferreo 
when  the  model  is  intended  to  show  what  happens  rather  than  a  design  of  how  it  happens. 


Diagram  Number  -  The  node  number  indicates  a  diagram's  place  in  a  model.  A  lower 
level  diagram's  node  number  is  constructed  from  the  node  number  of  the  upper  level 
diagram  box  number.  AO,  Al,  A2,  A  12,  A  121,  etc.  The  node  number  appears  in  the 
box  at  the  lower  left  of  each  diagram. 


The  model  is  presented  as  a  series  of  facing  pages.  In  each  pair  of  facing  pages,  a 
diagram  is  presented  opposite  the  text  which  discusses  the  diagram.  Except  in  the  first 
page  pair,  the  text  is  accompanied  by  a  'parent'  diagram  in  which  the  box  detailed  by  the 
diagram  has  been  shaded.  The  first  page  pair  summarizes  the  model,  therefore  there  is  no 
'parent'  diagram. 
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A.3  Node  List  For  AFIRMS  Methodology  Model, 


A-G  Obtain  and  Apply  Capability  Information  (Context) 

AO  Obtain  ana  Apply  Capability  Information 
A 1  T  ranslate  T  asking 

A 1 1  Select  or  Pass  On  T asking 
A 12  Add  Assumptions  for  Current  Level 
A13  Distribute  Over  Units 
A 14  Compare  Results  to  User  Needs 
A2  Define  Resources 

A21  Track  Current  Resource  Status 
A22  Store  and  Retrieve  Data 
A23  Forecast  Changes 

A231  Build  and  Update  Database 
A232  Forecast  Use  Before  Assessment  Period 
A233  Plan  Deliveries  to  AF  by  Category 
A 234  Track  Pre-Assessment  Balances 
A235  Track  balances  During  Assessment 
A 24  Plan  Distribution 
A25  Compare  Results  to  User  Needs 
A3  Determine  Ability  to  Perform 
A31  Propose  Schedule 
A32  Develop  and  Apply  Historic  Factors 
A33  Assess  Resource  Use 
A4  Aggregate,  Analyze,  and  Present  Data 
A41  Aggregate 
A42  Analyze 
A43  Present  Data 
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A.4  AFIRMS  Methodology  Model 
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AO.  Obtain  and  Apply  Capability  Information 
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With  order  and  resource  information  available,  the 
capability  can  then  be  evaulated. 


OBTAIN  AND  APPLY 


might  assist  the  user  --  or  even  an  algorithm  --  in 
iterating  to  a  better  set  of  assumptions  or  a  better 
distribution  of  the  task. 
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DATE 

INSERT 

4-29,  4-30 

31 

May 

1985 

4-29,  4-30/CHG1 ,  4-30.1/CHG1 

5-3,  5-4,  5-5,  5-6 

31 

May 

1985 

5-3,  5-4/CHG1 ,  5-4. 1/CHG1 , 
5-5/CHG1,  5-6 

5-7,  5-8 

31 

May 

1985 

5-7,  5-8/CHG1 ,  5-8. 1/CHG1 

7-1,  7-2 

31 

May 

1985 

7-1/CHG1 ,  7-1 . 1/CHG1 ,  7-2 

7-5 

31  May 

1985 

7-5/CHG1 

